Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches)

[ Note redirection to hackers list ]

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> It should actually almost work to write sq.nextval as things stand,
>> because Postgres has for a long time considered table.function and
>> function(table) to be interchangeable notations for certain kinds of

> May I wonder what the point and value of that practice is and why one
> would want to extend it further?

I think the reason the Berkeley guys did it originally was to support
functions that return tuples, and in particular extracting individual
columns of such a function's result. They didn't want to allow

function(sourcetable).column

(for reasons not real clear to me, but maybe they had good ones),
so they wrote it as

sourcetable.function.column

This actually still works; you can find examples in the regress tests.

My first reaction to Jeroen's patch was that it was a good idea poorly
implemented. I've never liked nextval('sequenceobject') from a
syntactic point of view, because a quoted string isn't an identifier
but you really want to have a normal SQL identifier to name the sequence.
(For example, right now we have some truly ugly hacks to try to make
that constant behave like a regular identifier as far as
case-folding-or-not-case-folding goes.)

It'd be a lot nicer if the syntax could be just nextval(sequencename)
or sequencename.nextval. And since you can select parameters of the
sequence with sequencename.field, why shouldn't sequencename.nextval
work?

However, on second thought I wonder if we'd be opening a can of worms
to do it that way. If I write

SELECT a, foo.b FROM bar;

what I actually get is a join across tables foo and bar --- foo is
implicitly added to the FROM list. Now, if I were to write

SELECT a, foo.nextval FROM bar;

presumably I don't want a join against the sequence foo, but I am not
sure that this will be clear either to a human reader or to the machine.
And if you think that's clear enough, what about

SELECT a, foo.nextval, foo.min_value FROM bar;

which surely *must* cause a true join to be generated, since min_value
is a perfectly ordinary field of foo?

So now I'm worried that making the sequence object visible as a table
identifier will cause strange misbehaviors, or at least great confusion.
This needs careful thought before we can accept it.

regards, tom lane

At 08:35 PM 12/16/99 -0500, Tom Lane wrote:

>presumably I don't want a join against the sequence foo, but I am not
>sure that this will be clear either to a human reader or to the machine.

I haven't personally heard of any human readers of Oracle SQL getting
confused by this notation... :)

On the other hand, I think nextval(foo) makes more sense, it's a
function operating on the sequence foo, not part of foo. nextval('foo')
is just bizarre, though it's clear and I can't say I worry much about
it now that I'm used to it!

In the porting-from-Oracle project I'm working on, we're just
regsub'ing all foo.nextval's into nextval('foo').

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

At 20:19 16-12-99 -0500, Tom Lane wrote:
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Applied nextval patch.
>
>I'm still not happy with it --- it may be in a different place, but it
>still breaks regular tables that have "nextval" or "currval" columns,
>because foo.nextval is still transformed to nextval('foo') regardless
>of whether foo is a sequence or not.
>
>
>What I was hoping for was something that would *first* determine whether
>foo is a sequence and *then* do the transformation only if so.
>This is obviously not possible at the grammar level (the grammar doesn't
>know what kind of table foo is, if indeed foo is a table at all), but
>ParseFuncOrColumn does have enough info to inspect foo's type.

I thought about this, but couldn't figure out how to test for foo being a
sequence.

>Now that I think about it, though, there are some potential semantic
>problems with the whole idea. See my about-to-be-written response to
>Peter's comment.
>
> > I don't agree with the parts of the patch, and
> > did not apply them.
>
>I believe his patch to bin/psql/describe.c is reasonable. Evidently
>he's dealing with a C compiler that tries to fold multi-part strings
>into one part during preprocessing, and it's getting confused by
>the conditional compilation of one line of the string. His proposed
>fix is more readable than the original code anyway, IMHO.

Yes, I needed this to get psql to compile at all.

>I'm dubious about the other two patches also. Evidently there is some
>variation across platforms in the desirable switches for ctags --- but
>diking out the ones not wanted on a particular platform is no answer.
>Perhaps the proper fix is to make the ctags flags a configurable
>macro...

The difference in the copyright notice patch is just extending the 1994 -
1999 to 2000 and aligning the quotes.

About ctags: is no one using Linux and ctags on the Postgres sources? Am I
the first one to find this bug?

At 20:35 16-12-99 -0500, Tom Lane wrote:
>Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >> It should actually almost work to write sq.nextval as things stand,
> >> because Postgres has for a long time considered table.function and
> >> function(table) to be interchangeable notations for certain kinds of
>
> > May I wonder what the point and value of that practice is and why one
> > would want to extend it further?
>
>I think the reason the Berkeley guys did it originally was to support
>functions that return tuples, and in particular extracting individual
>columns of such a function's result. They didn't want to allow
>
> function(sourcetable).column
>
>(for reasons not real clear to me, but maybe they had good ones),
>so they wrote it as
>
> sourcetable.function.column
>
>This actually still works; you can find examples in the regress tests.
>
>My first reaction to Jeroen's patch was that it was a good idea poorly
>implemented. I've never liked nextval('sequenceobject') from a
>syntactic point of view, because a quoted string isn't an identifier
>but you really want to have a normal SQL identifier to name the sequence.
>(For example, right now we have some truly ugly hacks to try to make
>that constant behave like a regular identifier as far as
>case-folding-or-not-case-folding goes.)
>
>It'd be a lot nicer if the syntax could be just nextval(sequencename)
>or sequencename.nextval. And since you can select parameters of the
>sequence with sequencename.field, why shouldn't sequencename.nextval
>work?
>
>However, on second thought I wonder if we'd be opening a can of worms
>to do it that way. If I write
>
> SELECT a, foo.b FROM bar;
>
>what I actually get is a join across tables foo and bar --- foo is
>implicitly added to the FROM list. Now, if I were to write
>
> SELECT a, foo.nextval FROM bar;
>
>presumably I don't want a join against the sequence foo, but I am not
>sure that this will be clear either to a human reader or to the machine.
>And if you think that's clear enough, what about
>
> SELECT a, foo.nextval, foo.min_value FROM bar;
>
>which surely *must* cause a true join to be generated, since min_value
>is a perfectly ordinary field of foo?
>
>So now I'm worried that making the sequence object visible as a table
>identifier will cause strange misbehaviors, or at least great confusion.
>This needs careful thought before we can accept it.

I didn't think about these complications at all (thought that my small
patch would just add a little more compatibility with a minimum of fuss,
but I was wrong). Let me investigate whether I can come up with a better
solution.

Cheers,

Jeroen

OK, I have read this. Please give me reasons for any patches you
supply. I would be glad to apply the patch you needed to get psql to
compile if you sent it to me again. I had no idea why the change was
being made. Same for the copyright change.

> At 20:19 16-12-99 -0500, Tom Lane wrote:
> >Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Applied nextval patch.
> >
> >I'm still not happy with it --- it may be in a different place, but it
> >still breaks regular tables that have "nextval" or "currval" columns,
> >because foo.nextval is still transformed to nextval('foo') regardless
> >of whether foo is a sequence or not.
> >
> >
> >What I was hoping for was something that would *first* determine whether
> >foo is a sequence and *then* do the transformation only if so.
> >This is obviously not possible at the grammar level (the grammar doesn't
> >know what kind of table foo is, if indeed foo is a table at all), but
> >ParseFuncOrColumn does have enough info to inspect foo's type.
>
> I thought about this, but couldn't figure out how to test for foo being a
> sequence.
>
>
> >Now that I think about it, though, there are some potential semantic
> >problems with the whole idea. See my about-to-be-written response to
> >Peter's comment.
> >
> > > I don't agree with the parts of the patch, and
> > > did not apply them.
> >
> >I believe his patch to bin/psql/describe.c is reasonable. Evidently
> >he's dealing with a C compiler that tries to fold multi-part strings
> >into one part during preprocessing, and it's getting confused by
> >the conditional compilation of one line of the string. His proposed
> >fix is more readable than the original code anyway, IMHO.
>
> Yes, I needed this to get psql to compile at all.
>
> >I'm dubious about the other two patches also. Evidently there is some
> >variation across platforms in the desirable switches for ctags --- but
> >diking out the ones not wanted on a particular platform is no answer.
> >Perhaps the proper fix is to make the ctags flags a configurable
> >macro...
>
> The difference in the copyright notice patch is just extending the 1994 -
> 1999 to 2000 and aligning the quotes.
>
> About ctags: is no one using Linux and ctags on the Postgres sources? Am I
> the first one to find this bug?
>
> At 20:35 16-12-99 -0500, Tom Lane wrote:
> >Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > >> It should actually almost work to write sq.nextval as things stand,
> > >> because Postgres has for a long time considered table.function and
> > >> function(table) to be interchangeable notations for certain kinds of
> >
> > > May I wonder what the point and value of that practice is and why one
> > > would want to extend it further?
> >
> >I think the reason the Berkeley guys did it originally was to support
> >functions that return tuples, and in particular extracting individual
> >columns of such a function's result. They didn't want to allow
> >
> > function(sourcetable).column
> >
> >(for reasons not real clear to me, but maybe they had good ones),
> >so they wrote it as
> >
> > sourcetable.function.column
> >
> >This actually still works; you can find examples in the regress tests.
> >
> >My first reaction to Jeroen's patch was that it was a good idea poorly
> >implemented. I've never liked nextval('sequenceobject') from a
> >syntactic point of view, because a quoted string isn't an identifier
> >but you really want to have a normal SQL identifier to name the sequence.
> >(For example, right now we have some truly ugly hacks to try to make
> >that constant behave like a regular identifier as far as
> >case-folding-or-not-case-folding goes.)
> >
> >It'd be a lot nicer if the syntax could be just nextval(sequencename)
> >or sequencename.nextval. And since you can select parameters of the
> >sequence with sequencename.field, why shouldn't sequencename.nextval
> >work?
> >
> >However, on second thought I wonder if we'd be opening a can of worms
> >to do it that way. If I write
> >
> > SELECT a, foo.b FROM bar;
> >
> >what I actually get is a join across tables foo and bar --- foo is
> >implicitly added to the FROM list. Now, if I were to write
> >
> > SELECT a, foo.nextval FROM bar;
> >
> >presumably I don't want a join against the sequence foo, but I am not
> >sure that this will be clear either to a human reader or to the machine.
> >And if you think that's clear enough, what about
> >
> > SELECT a, foo.nextval, foo.min_value FROM bar;
> >
> >which surely *must* cause a true join to be generated, since min_value
> >is a perfectly ordinary field of foo?
> >
> >So now I'm worried that making the sequence object visible as a table
> >identifier will cause strange misbehaviors, or at least great confusion.
> >This needs careful thought before we can accept it.
>
> I didn't think about these complications at all (thought that my small
> patch would just add a little more compatibility with a minimum of fuss,
> but I was wrong). Let me investigate whether I can come up with a better
> solution.
>
>
> Cheers,
>
> Jeroen
>
>
> ************
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

On 1999-12-17, Jeroen van Vianen mentioned:

> The difference in the copyright notice patch is just extending the 1994 -
> 1999 to 2000 and aligning the quotes.

I believe that at one point we came to a sort-of conclusion that this
whole deal is (C) UCB until 1995(6?) and (C) PostgreSQL Global Development
Group 1996-present. Don't give intellectual property to people that didn't
do anything.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

> > The difference in the copyright notice patch is just extending the 1994 -
> > 1999 to 2000 and aligning the quotes.
> I believe that at one point we came to a sort-of conclusion that this
> whole deal is (C) UCB until 1995(6?) and (C) PostgreSQL Global Development
> Group 1996-present. Don't give intellectual property to people that didn't
> do anything.

Yes, this is the way we should be annotating Postgres afaik. UCB would
be aghast to find that they need to defend themselves against all of
the changes in the last three years :)

Do we now have things in the code tree which do not carry two
copyrights, or just the Postgres Dev Group copyright plus a reference
to the full text in the docs?

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

Thomas Lockhart wrote:

> Do we now have things in the code tree which do not carry two
> copyrights, or just the Postgres Dev Group copyright plus a reference
> to the full text in the docs?

Seen some recently - wait...

backend/optimizer/geqo/... (c) 1990 Darrell L. Whitley

backend/port/inet_aton.* Outch - see below
* This inet_aton() function was taken from the GNU C library and
* incorporated into Postgres for those systems which do not have this
* routine in their standard C libraries.
*
* The function was been extracted whole from the file inet_aton.c in
* Release 5.3.12 of the Linux C library, which is derived from the
* GNU C library, by Bryan Henderson in October 1996. The copyright
* notice from that file is below.

backend/port/snprintf.c (c) 1993 Eric P. Allman
backend/port/dynloader/aix.* (c) 1992 HELIOS Software GmbH
backend/port/dynloader/qnx4.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/isnan.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/rint.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/sem.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/shm.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/tstrint.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/tstsem.c (c) 1999, repas AEG Automation GmbH
backend/port/qnx4/tstshm.c (c) 1999, repas AEG Automation GmbH
backend/regex/... (c) 1992, 1993, 1994 Henry Spencer.
backend/utils/adt/float.c (c) 1994 by Sun Microsystems, Inc. (line 1510)
backend/utils/adt/geo_ops.c (c) 1995 <by John Franks>
backend/utils/adt/inet_net_ntop.c (c) 1996 by Internet Software Consortium.
backend/utils/adt/inet_net_pton.c (c) 1996 by Internet Software Consortium.
backend/utils/adt/ruleutils.c (c) Jan Wieck :-) - I'll remove that.

backend/utils/mb/big5.c
* conversion between BIG5 and Mule Internal Code(CNS 116643-1992
* plane 1 and plane 2).
* This program is partially copied from lv(Multilingual file viewer)
* and slightly modified. lv is written and copyrighted by NARITA Tomio
* (nrt(at)web(dot)ad(dot)jp).

That's all I can find that quick.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

Well, that's a royal mess. Guess we can remove the code if someone asks
us to? Not much more we can do.

> Thomas Lockhart wrote:
>
> > Do we now have things in the code tree which do not carry two
> > copyrights, or just the Postgres Dev Group copyright plus a reference
> > to the full text in the docs?
>
> Seen some recently - wait...
>
> backend/optimizer/geqo/... (c) 1990 Darrell L. Whitley
>
> backend/port/inet_aton.* Outch - see below
> * This inet_aton() function was taken from the GNU C library and
> * incorporated into Postgres for those systems which do not have this
> * routine in their standard C libraries.
> *
> * The function was been extracted whole from the file inet_aton.c in
> * Release 5.3.12 of the Linux C library, which is derived from the
> * GNU C library, by Bryan Henderson in October 1996. The copyright
> * notice from that file is below.
>
> backend/port/snprintf.c (c) 1993 Eric P. Allman
> backend/port/dynloader/aix.* (c) 1992 HELIOS Software GmbH
> backend/port/dynloader/qnx4.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/isnan.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/rint.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/sem.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/shm.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/tstrint.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/tstsem.c (c) 1999, repas AEG Automation GmbH
> backend/port/qnx4/tstshm.c (c) 1999, repas AEG Automation GmbH
> backend/regex/... (c) 1992, 1993, 1994 Henry Spencer.
> backend/utils/adt/float.c (c) 1994 by Sun Microsystems, Inc. (line 1510)
> backend/utils/adt/geo_ops.c (c) 1995 <by John Franks>
> backend/utils/adt/inet_net_ntop.c (c) 1996 by Internet Software Consortium.
> backend/utils/adt/inet_net_pton.c (c) 1996 by Internet Software Consortium.
> backend/utils/adt/ruleutils.c (c) Jan Wieck :-) - I'll remove that.
>
> backend/utils/mb/big5.c
> * conversion between BIG5 and Mule Internal Code(CNS 116643-1992
> * plane 1 and plane 2).
> * This program is partially copied from lv(Multilingual file viewer)
> * and slightly modified. lv is written and copyrighted by NARITA Tomio
> * (nrt(at)web(dot)ad(dot)jp).
>
> That's all I can find that quick.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #========================================= wieck(at)debis(dot)com (Jan Wieck) #
>
>
>
> ************
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> Well, that's a royal mess. Guess we can remove the code if someone asks
> us to? Not much more we can do.

I think the issue is the license term, not the copyright. In my
opinion, we could live with copyrights other than ours as long as
their licenses are as free as the PostgreSQL license.

>
> > Thomas Lockhart wrote:
> >
> > > Do we now have things in the code tree which do not carry two
> > > copyrights, or just the Postgres Dev Group copyright plus a reference
> > > to the full text in the docs?
> >
> > Seen some recently - wait...
> >
> > backend/optimizer/geqo/... (c) 1990 Darrell L. Whitley

>From the source code:
>Permission is hereby granted to copy all or any part of
>this program for free distribution. The author's name
>and this copyright notice must be included in any copy.

This looks safe for me.

> > backend/port/inet_aton.* Outch - see below
> > * This inet_aton() function was taken from the GNU C library and
> > * incorporated into Postgres for those systems which do not have this
> > * routine in their standard C libraries.

Seems bad for us, since they are GPL'd...

> > backend/port/snprintf.c (c) 1993 Eric P. Allman

Looks good. Its licence is BSD.

> > backend/port/dynloader/aix.* (c) 1992 HELIOS Software GmbH

/*
* @(#)dlfcn.c 1.7 revision of 95/08/14 19:08:38
* This is an unpublished work copyright (c) 1992 HELIOS Software GmbH
* 30159 Hannover, Germany
*/

Not sure about above.

> > backend/port/dynloader/qnx4.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/isnan.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/rint.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/sem.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/shm.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/tstrint.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/tstsem.c (c) 1999, repas AEG Automation GmbH
> > backend/port/qnx4/tstshm.c (c) 1999, repas AEG Automation GmbH

Nothing is mentioned about the license. We could ask the author about
it.

> > backend/regex/... (c) 1992, 1993, 1994 Henry Spencer.

> * Copyright (c) 1992, 1993, 1994 Henry Spencer.
> * Copyright (c) 1992, 1993, 1994
> * The Regents of the University of California. All rights reserved.
> *
> * This code is derived from software contributed to Berkeley by
> * Henry Spencer.

Seems ok for me.

> > backend/utils/adt/float.c (c) 1994 by Sun Microsystems, Inc. (line 1510)

> * Developed at SunPro, a Sun Microsystems, Inc. business.
> * Permission to use, copy, modify, and distribute this
> * software is freely granted, provided that this notice
> * is preserved.

Also good.

> > backend/utils/adt/geo_ops.c (c) 1995 <by John Franks>

> * (code offered for use by J. Franks in Linux Journal letter.)

This indicates it's safe?

> > backend/utils/adt/inet_net_ntop.c (c) 1996 by Internet Software Consortium.
> > backend/utils/adt/inet_net_pton.c (c) 1996 by Internet Software Consortium.

License term seems ok for us.

> > backend/utils/adt/ruleutils.c (c) Jan Wieck :-) - I'll remove that.

I think he could leave his copyright, but it is up to him...

> > backend/utils/mb/big5.c
> > * conversion between BIG5 and Mule Internal Code(CNS 116643-1992
> > * plane 1 and plane 2).
> > * This program is partially copied from lv(Multilingual file viewer)
> > * and slightly modified. lv is written and copyrighted by NARITA Tomio
> > * (nrt(at)web(dot)ad(dot)jp).

I contacted the author when I borrowed his code. At that time its
license seemed to be sort of "public domain." But today I found on his
web page (http://www.ff.iij4u.or.jp/~nrt/lv/) that he seems changed
the license to GPL2. This is bad news for me, so I have written to him
about it and am waiting for his reply...
--
Tatsuo Ishii

> > > backend/utils/mb/big5.c
> > > * conversion between BIG5 and Mule Internal Code(CNS 116643-1992
> > > * plane 1 and plane 2).
> > > * This program is partially copied from lv(Multilingual file viewer)
> > > * and slightly modified. lv is written and copyrighted by NARITA Tomio
> > > * (nrt(at)web(dot)ad(dot)jp).
>
> I contacted the author when I borrowed his code. At that time its
> license seemed to be sort of "public domain." But today I found on his
> web page (http://www.ff.iij4u.or.jp/~nrt/lv/) that he seems changed
> the license to GPL2. This is bad news for me, so I have written to him
> about it and am waiting for his reply...

I have gotten a reply from him. He has changed the license term
*after* I copied the code from it. And he and I regard it is ok to use
the codes for PostgreSQL under the old license term.
--
Tatsuo Ishii