Files
postgresql/src/test/regress/input/misc.source
Andres Freund 5ded4bd214 Remove support for version-0 calling conventions.
The V0 convention is failure prone because we've so far assumed that a
function is V0 if PG_FUNCTION_INFO_V1 is missing, leading to crashes
if a function was coded against the V1 interface.  V0 doesn't allow
proper NULL, SRF and toast handling.  V0 doesn't offer features that
V1 doesn't.

Thus remove V0 support and obsolete fmgr README contents relating to
it.

Author: Andres Freund, with contributions by Peter Eisentraut & Craig Ringer
Reviewed-By: Peter Eisentraut, Craig Ringer
Discussion: https://postgr.es/m/20161208213441.k3mbno4twhg2qf7g@alap3.anarazel.de
2017-03-30 06:25:46 -07:00

263 lines
5.4 KiB
Plaintext

--
-- MISC
--
--
-- BTREE
--
UPDATE onek
SET unique1 = onek.unique1 + 1;
UPDATE onek
SET unique1 = onek.unique1 - 1;
--
-- BTREE partial
--
-- UPDATE onek2
-- SET unique1 = onek2.unique1 + 1;
--UPDATE onek2
-- SET unique1 = onek2.unique1 - 1;
--
-- BTREE shutting out non-functional updates
--
-- the following two tests seem to take a long time on some
-- systems. This non-func update stuff needs to be examined
-- more closely. - jolly (2/22/96)
--
UPDATE tmp
SET stringu1 = reverse_name(onek.stringu1)
FROM onek
WHERE onek.stringu1 = 'JBAAAA' and
onek.stringu1 = tmp.stringu1;
UPDATE tmp
SET stringu1 = reverse_name(onek2.stringu1)
FROM onek2
WHERE onek2.stringu1 = 'JCAAAA' and
onek2.stringu1 = tmp.stringu1;
DROP TABLE tmp;
--UPDATE person*
-- SET age = age + 1;
--UPDATE person*
-- SET age = age + 3
-- WHERE name = 'linda';
--
-- copy
--
COPY onek TO '@abs_builddir@/results/onek.data';
DELETE FROM onek;
COPY onek FROM '@abs_builddir@/results/onek.data';
SELECT unique1 FROM onek WHERE unique1 < 2 ORDER BY unique1;
DELETE FROM onek2;
COPY onek2 FROM '@abs_builddir@/results/onek.data';
SELECT unique1 FROM onek2 WHERE unique1 < 2 ORDER BY unique1;
COPY BINARY stud_emp TO '@abs_builddir@/results/stud_emp.data';
DELETE FROM stud_emp;
COPY BINARY stud_emp FROM '@abs_builddir@/results/stud_emp.data';
SELECT * FROM stud_emp;
-- COPY aggtest FROM stdin;
-- 56 7.8
-- 100 99.097
-- 0 0.09561
-- 42 324.78
-- .
-- COPY aggtest TO stdout;
--
-- inheritance stress test
--
SELECT * FROM a_star*;
SELECT *
FROM b_star* x
WHERE x.b = text 'bumble' or x.a < 3;
SELECT class, a
FROM c_star* x
WHERE x.c ~ text 'hi';
SELECT class, b, c
FROM d_star* x
WHERE x.a < 100;
SELECT class, c FROM e_star* x WHERE x.c NOTNULL;
SELECT * FROM f_star* x WHERE x.c ISNULL;
-- grouping and aggregation on inherited sets have been busted in the past...
SELECT sum(a) FROM a_star*;
SELECT class, sum(a) FROM a_star* GROUP BY class ORDER BY class;
ALTER TABLE f_star RENAME COLUMN f TO ff;
ALTER TABLE e_star* RENAME COLUMN e TO ee;
ALTER TABLE d_star* RENAME COLUMN d TO dd;
ALTER TABLE c_star* RENAME COLUMN c TO cc;
ALTER TABLE b_star* RENAME COLUMN b TO bb;
ALTER TABLE a_star* RENAME COLUMN a TO aa;
SELECT class, aa
FROM a_star* x
WHERE aa ISNULL;
-- As of Postgres 7.1, ALTER implicitly recurses,
-- so this should be same as ALTER a_star*
ALTER TABLE a_star RENAME COLUMN aa TO foo;
SELECT class, foo
FROM a_star* x
WHERE x.foo >= 2;
ALTER TABLE a_star RENAME COLUMN foo TO aa;
SELECT *
from a_star*
WHERE aa < 1000;
ALTER TABLE f_star ADD COLUMN f int4;
UPDATE f_star SET f = 10;
ALTER TABLE e_star* ADD COLUMN e int4;
--UPDATE e_star* SET e = 42;
SELECT * FROM e_star*;
ALTER TABLE a_star* ADD COLUMN a text;
-- That ALTER TABLE should have added TOAST tables.
SELECT relname, reltoastrelid <> 0 AS has_toast_table
FROM pg_class
WHERE oid::regclass IN ('a_star', 'c_star')
ORDER BY 1;
--UPDATE b_star*
-- SET a = text 'gazpacho'
-- WHERE aa > 4;
SELECT class, aa, a FROM a_star*;
--
-- versions
--
--
-- postquel functions
--
--
-- mike does post_hacking,
-- joe and sally play basketball, and
-- everyone else does nothing.
--
SELECT p.name, name(p.hobbies) FROM ONLY person p;
--
-- as above, but jeff also does post_hacking.
--
SELECT p.name, name(p.hobbies) FROM person* p;
--
-- the next two queries demonstrate how functions generate bogus duplicates.
-- this is a "feature" ..
--
SELECT DISTINCT hobbies_r.name, name(hobbies_r.equipment) FROM hobbies_r
ORDER BY 1,2;
SELECT hobbies_r.name, (hobbies_r.equipment).name FROM hobbies_r;
--
-- mike needs advil and peet's coffee,
-- joe and sally need hightops, and
-- everyone else is fine.
--
SELECT p.name, name(p.hobbies), name(equipment(p.hobbies)) FROM ONLY person p;
--
-- as above, but jeff needs advil and peet's coffee as well.
--
SELECT p.name, name(p.hobbies), name(equipment(p.hobbies)) FROM person* p;
--
-- just like the last two, but make sure that the target list fixup and
-- unflattening is being done correctly.
--
SELECT name(equipment(p.hobbies)), p.name, name(p.hobbies) FROM ONLY person p;
SELECT (p.hobbies).equipment.name, p.name, name(p.hobbies) FROM person* p;
SELECT (p.hobbies).equipment.name, name(p.hobbies), p.name FROM ONLY person p;
SELECT name(equipment(p.hobbies)), name(p.hobbies), p.name FROM person* p;
SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer')));
SELECT name(equipment(hobby_construct_named(text 'skywalking', text 'mer')));
SELECT name(equipment_named(hobby_construct_named(text 'skywalking', text 'mer')));
SELECT name(equipment_named_ambiguous_1a(hobby_construct_named(text 'skywalking', text 'mer')));
SELECT name(equipment_named_ambiguous_1b(hobby_construct_named(text 'skywalking', text 'mer')));
SELECT name(equipment_named_ambiguous_1c(hobby_construct_named(text 'skywalking', text 'mer')));
SELECT name(equipment_named_ambiguous_2a(text 'skywalking'));
SELECT name(equipment_named_ambiguous_2b(text 'skywalking'));
SELECT hobbies_by_name('basketball');
SELECT name, overpaid(emp.*) FROM emp;
--
-- Try a few cases with SQL-spec row constructor expressions
--
SELECT * FROM equipment(ROW('skywalking', 'mer'));
SELECT name(equipment(ROW('skywalking', 'mer')));
SELECT *, name(equipment(h.*)) FROM hobbies_r h;
SELECT *, (equipment(CAST((h.*) AS hobbies_r))).name FROM hobbies_r h;
--
-- functional joins
--
--
-- instance rules
--
--
-- rewrite rules
--