Re: Sequence usage patch

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

On Fri, 2003-06-06 at 11:17, Bruce Momjian wrote:
> 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?

Thats about what it boils down to.

People seem to prefer Oracle compatibility over DB2 compatibility, so
I'm going to hold it until the next spec is released.

> 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!
--
Rod Taylor <rbt(at)rbt(dot)ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2003-06-06 15:53:17 Re: Problems with renaming a column
Previous Message Lamar Owen 2003-06-06 15:33:04 Re: Wrong version of jdbc in 7.3.3 rpms

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2003-06-06 16:21:54 Re: Bug in metaphone (contrib/fuzzystrmatch)
Previous Message Bruce Momjian 2003-06-06 15:33:16 Re: Lonely Patch Seeks Long-Term Commitment to Codebase