Re: [HACKERS] Re: [GENERAL] Bug with sequences in 6.4.2

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> CREATE SEQUENCE "AA";
> >> -- Correct, quoted identifier is allowed;
> >> SELECT NEXTVAL('AA');
> >> --Produces Error
> 
> > Let me comment on this.    In the first statement, "AA" is used in an
> > SQL command, and we handle this correctly.  In the second case, NEXTVAL
> > is a function, called with a string.
> > Now in parse_func.c, we convert 'AA' to lower to try and find the
> > sequence table.  My assumption is that we should attempt to find the
> > table without doing a lower(), and if that fails, try lower.
> > Does that make sense to people.  We can't just lower it in every case.
> 
> That would create an ambiguity that is better avoided.  I think nextval
> ought to duplicate the parser's behavior --- if possible, actually call
> the same routine the parser uses for looking up a sequence name.
> I suggest that it operate like this:
> 
> (1)    nextval('AA')        operates on sequence aa
> 
>     AA is lowercased, same as unquoted AA would be by the parser.
> 
> (2)    nextval('"AA"')        operates on sequence AA
> 
>     Quoted "AA" is treated as AA, same as parser would do it.
> 
> This should be fully backward compatible with existing SQL code, since
> the existing nextval() code implements case (1).  I doubt anyone has
> tried putting double quotes into their nextval arguments, so adding
> the case (2) behavior shouldn't break anything.

I can do that.  It looked kind of strange.  Usually they do:
create sequence "Aa";

Because nextval is a function with a parameter, it would be
nextval('"Aa"').  I don't think we want to do this for all function
parameters, but just for nextval.

I can do that.

--  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