Re: Sequence usage patch

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Sequence usage patch
Date: 2003-06-06 15:17:43
Message-ID: 200306061517.h56FHh119163@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


There was a lot of discussion about this patch, and shorter version
posted with just the CURRENT part. However, I think some felt that this
wasn't a standard yet, and therefore weren't ready to implement this.
Is that correct?

---------------------------------------------------------------------------

Rod Taylor wrote:
-- Start of PGP signed section.
> Enables syntax: NEXT VALUE FOR <seqname> and CURRENT VALUE FOR <seqname>
>
> The 200N spec is based on DB2, not MSSQL, so it is very likely NEXT
> VALUE FOR will be the official syntax.
>
> http://216.239.37.100/search?q=cache:s5eWP72lHKcJ:www7b.software.ibm.com/dmdd/library/techarticle/0302fielding/0302fielding.html+%22Bobby+Fielding%22+&hl=en&lr=lang_en&ie=UTF-8
>
> DB2 uses PREVIOUS VALUE FOR <seqname> as their currval() (nothing in
> spec about this). I don't see PREVIOUS as a reserved word, but CURRENT
> certainly is -- WHERE CURRENT OF for cursors, and several other places.
>
> The attached patch makes CURRENT a reserved word. VALUE is treated as
> an IDENT to preserve the ability to use it as a column.
>
> SequenceOp is the node (primnode) used in the executor, and required
> splitting up nextval / currval into public and internal interfaces. The
> internal interface operates on the sequence OID, and the public
> interface on the sequence name as usual.
>
> Dependencies are recorded for the SequenceOp node so now we cannot drop
> a sequence used in a default expression.
>
> I've not figured out the best place to record the dependency to prevent
> the default expression from being changed for SERIAL columns yet, but
> that should be a separate patch. The concept of a serial will need to
> be brought in deeper than parser/analyze.c for this to happen.
>
> No documentation changes attached. I want to know whether this would be
> applied before I make those.
>
>
> Tom,
>
> Should I have created another parser node strictly for the gram.y stuff,
> then had it copy the info to the primnode within parse_expr.c? As it
> is, SequenceOp is left with a hanging RangeVar that is unused past that
> point.
> --
> Rod Taylor <rbt(at)rbt(dot)ca>
>
> PGP Key: http://www.rbt.ca/rbtpub.asc

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-06 15:25:52 Re: [HACKERS] Removing a user's password
Previous Message Bruce Momjian 2003-06-06 15:14:55 Re: [HACKERS] Removing a user's password

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-06-06 15:25:52 Re: [HACKERS] Removing a user's password
Previous Message Bruce Momjian 2003-06-06 15:14:55 Re: [HACKERS] Removing a user's password