Thread: Notation for nextval() (was Re: Several small patches)
[ Note redirection to hackers list ]
Peter Eisentraut <peter_e@gmx.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@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
At 20:19 16-12-99 -0500, Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.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@gmx.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@candle.pha.pa.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@gmx.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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Jeroen van Vianen <jeroen@design.nl> writes:
>> 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...
> About ctags: is no one using Linux and ctags on the Postgres sources? Am I
> the first one to find this bug?
Apparently you're a little new to the world of portable software.
I don't use ctags myself, being an Emacs man rather than a vi'er,
but a few minutes' research yielded the following results:
GNU ctags (from Emacs 19.34 distribution): -a, -d, -t, -f accepted.
HPUX ctags (which claims to be based on the original UCB code and
compliant to XPG4 standard): -a, -t, but no -d nor -f.
SunOS 4.1: same as HPUX.
RedHat 4.2 Linux: comes with something called "Exuberant Ctags, Version
1.5" which accepts all four (apparently this is NOT the same code as the
GNU distribution).
Whatever Linux you're running: evidently only -a and -f.
I don't know which variant of ctags you're running, but it's definitely
odd man out as far as not accepting -t goes. I'd certainly want to use
-d (index #defines) anywhere it was accepted, too. Other side of the
coin is that -a is the only one of these switches that works on all the
ctags versions I was able to lay my hands on in five minutes plus yours.
That should give you some pause about asserting that if -a -f is the
right incantation for the version you have, then it must be the right
thing for everybody.
Bottom line here is that what we probably really need is a configurable
makefile macro for the ctags switches. (In fact, what I'd personally
like is another macro to determine whether we're using ctags or etags in
the first place ;-).) But short of that, I'd definitely lean towards
the GNU definition as being the most widespread code. I'm pretty
surprised that your Linux distribution (which one is it?) seems to
contain a non-GNU-compatible ctags.
regards, tom lane
Jeroen van Vianen <jeroen@design.nl> writes:
>> What I was hoping for was something that would *first* determine whether
>> foo is a sequence and *then* do the transformation only if so.
> I thought about this, but couldn't figure out how to test for foo being a
> sequence.
IIRC, foo is a sequence if it has relkind 'S'. You can check the
relkind by looking into the struct returned by heap_open. The main
thing that needs to be thought about is how to ensure that the sequence
object won't be added to the query's rangetable list if it is used in
a way that looks like a table reference. It may be that hacking up
ParseFuncOrColumn will be enough to prevent that, or it may not...
regards, tom lane
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@gmx.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@alumni.caltech.edu
South Pasadena, California
Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches)
From
wieck@debis.com (Jan Wieck)
Date:
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@web.ad.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@debis.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@web.ad.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@debis.com (Jan Wieck) # > > > > ************ > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> 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@web.ad.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@web.ad.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