"Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 | 4567890123456912
4567890123456789 | 123 | 4567890123456912 | 4567890123456912
4567890123456789 | 4567890123456789 | 9135780246913578 | 9135780246913578
4567890123456789 | -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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
