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.

regards, tom lane