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

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(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