Thread: Re: [PATCHES] Sequence usage patch

(Moved to -hackers)

> Rod Taylor <rbt@rbt.ca> writes:
> > Are you ok with the DB2 and draft-spec syntax of NEXT VALUE FOR (where
> > value is not a reserved word)?  Or should I hold onto that until the
> > spec has gone through the final draft / release?
>
> By that time we'll have done the Oracle-style foo.nextval, and it'll
> become kind of a moot point ;-)

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.  In fact, it's actually a bit bizarre when you start
going database.schema.sequence.nextval, etc.

The NEXT VALUE FOR syntax would be more in keeping with our current sytacies
methinks...

Chris

"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