"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> I actually like the NEXT VALUE FOR a lot more. The reason is that the
> Oracle syntax is very much an 'object.property' lookup, which we do nowhere
> else in PostgreSQL.
I beg to differ. We have supported table.function since day one ---
it's in the original Berkeley code. For example:
regression=# \d int8_tbl Table "public.int8_tbl"Column | Type | Modifiers
--------+--------+-----------q1 | bigint |q2 | bigint |
regression=# create function mysum(int8_tbl) returns int8 as '
regression'# select $1.q1 + $1.q2' language sql;
CREATE FUNCTION
regression=# select *, mysum(t1), t1.mysum from int8_tbl t1; q1 | q2 | mysum |
mysum
------------------+-------------------+------------------+------------------ 123 | 456 |
579 | 579 123 | 4567890123456789 | 4567890123456912 | 45678901234569124567890123456789
| 123 | 4567890123456912 | 45678901234569124567890123456789 | 4567890123456789 | 9135780246913578 |
91357802469135784567890123456789| -4567890123456789 | 0 | 0
(5 rows)
So syntactically, the Oracle notation is in our direct line of
inheritance from Berkeley. The only reason we can't quite get
foo.nextval to work today is that the system wants to put foo
into the query's FROM list, which we don't want for a sequence
reference.
regards, tom lane
