Thread: quotes in SET grammar
Christopher's patch to fix docs regarding single- and double-quotes in
SET syntax got me looking at gram.y. It turns out that although we allow
lists of double-quoted strings in SET, we do not allow lists of
single-quoted strings (the latter should have been preferred afaik). And
although we allow single-quoted strings in SET TIME ZONE, we do not
allow double-quoted strings! So things seem inconsistant to me.
Possible cases look like
SET TIME ZONE 'pst8pdt'; SET TIME ZONE "pst8pdt"; SET DATESTYLE = "US","ISO";
Is there any objection to allowing both single- and double-quoted
strings in SET? Or should I remove the double-quoted variety altogether?
I've got patches for the former, but am willing to consider either
solution. afaik single-quoted strings would be sufficient to cover
users' expectations, and all cases are extentions to SQL9x syntax, which
only specifies SET TIME ZONE with a numeric offset. Comments?
- Thomas
Thomas Lockhart wrote: > Christopher's patch to fix docs regarding single- and double-quotes in > SET syntax got me looking at gram.y. It turns out that although we allow > lists of double-quoted strings in SET, we do not allow lists of > single-quoted strings (the latter should have been preferred afaik). And > although we allow single-quoted strings in SET TIME ZONE, we do not > allow double-quoted strings! So things seem inconsistant to me. > > Possible cases look like > > SET TIME ZONE 'pst8pdt'; > SET TIME ZONE "pst8pdt"; > SET DATESTYLE = "US","ISO"; > > Is there any objection to allowing both single- and double-quoted > strings in SET? Or should I remove the double-quoted variety altogether? > I've got patches for the former, but am willing to consider either > solution. afaik single-quoted strings would be sufficient to cover > users' expectations, and all cases are extentions to SQL9x syntax, which > only specifies SET TIME ZONE with a numeric offset. Comments? I think only single quotes should be allowed. These are strings. The double-quotes have such a different meaning in SQL that their use seems confusing. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Thomas Lockhart <thomas@fourpalms.org> writes:
> Possible cases look like
> SET TIME ZONE 'pst8pdt';
> SET TIME ZONE "pst8pdt";
> SET DATESTYLE = "US","ISO";
> Is there any objection to allowing both single- and double-quoted
> strings in SET? Or should I remove the double-quoted variety altogether?
I think it would be best to disallow the double-quoted form. If we
allow it, then we will have a backwards-compatibility problem should
we ever want to generalize SET to accept an expression (because
double-quoted things are identifiers, not literals).
However, I'm not sure *how* to disallow it without also disallowing
unquoted words (since ultimately the productions reduce to ColId,
and the lexer output doesn't distinguish quoted and unquoted
identifiers). I don't think I want to go back to writingset whatever to 'on';
so I guess I'll have to just grin and bear it.
I agree that all the forms of SET should be consistent about what
kinds of quoted or unquoted words they will take.
regards, tom lane
...
> I think it would be best to disallow the double-quoted form...
> However, I'm not sure *how* to disallow it without also disallowing
> unquoted words (since ultimately the productions reduce to ColId,
> and the lexer output doesn't distinguish quoted and unquoted
> identifiers).
Well, that would be how to distinguish them; we could define a new
token, say "QIDENT" to refer to quoted identifiers and leave "IDENT" for
the unquoted ones. Then a little work in gram.y should be enough to
finish the job.
The use of IDENT in gram.y is isolated to just a few places so
introducing QIDENT would be almost trivial afaict.
- Thomas
>>> I think it would be best to disallow the double-quoted form...
Actually, on second thought that argument holds no water at all.
If we tried to extend SET to accept expressions, we'd have to break
compatibility with its acceptance of unquoted words, so breaking
the interpretation of double-quoted words too is no biggie. Certainly
there's no point in going through a lot of lexer and parser pushups
to disallow double-quoted words here.
So now my thought is not to document double-quote, but not to go out
of our way to disallow it either.
I still agree that all forms of SET should be consistent about what
they will take.
regards, tom lane
Thomas Lockhart <thomas@fourpalms.org> writes:
> The use of IDENT in gram.y is isolated to just a few places so
> introducing QIDENT would be almost trivial afaict.
True. Is it worth the trouble? Not sure...
regards, tom lane
Tom Lane wrote: > Thomas Lockhart <thomas@fourpalms.org> writes: > > Possible cases look like > > > SET TIME ZONE 'pst8pdt'; > > SET TIME ZONE "pst8pdt"; > > SET DATESTYLE = "US","ISO"; > > > Is there any objection to allowing both single- and double-quoted > > strings in SET? Or should I remove the double-quoted variety altogether? > > I think it would be best to disallow the double-quoted form. If we > allow it, then we will have a backwards-compatibility problem should > we ever want to generalize SET to accept an expression (because > double-quoted things are identifiers, not literals). > > However, I'm not sure *how* to disallow it without also disallowing > unquoted words (since ultimately the productions reduce to ColId, > and the lexer output doesn't distinguish quoted and unquoted > identifiers). I don't think I want to go back to writing > set whatever to 'on'; > so I guess I'll have to just grin and bear it. > > I agree that all the forms of SET should be consistent about what > kinds of quoted or unquoted words they will take. I see, because we allow non-quoted values, the quotes are accepted too. Makes sense. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Thomas Lockhart wrote: > ... > > I think it would be best to disallow the double-quoted form... > > However, I'm not sure *how* to disallow it without also disallowing > > unquoted words (since ultimately the productions reduce to ColId, > > and the lexer output doesn't distinguish quoted and unquoted > > identifiers). > > Well, that would be how to distinguish them; we could define a new > token, say "QIDENT" to refer to quoted identifiers and leave "IDENT" for > the unquoted ones. Then a little work in gram.y should be enough to > finish the job. > > The use of IDENT in gram.y is isolated to just a few places so > introducing QIDENT would be almost trivial afaict. Well, we allow single-quotes, and we allow no quotes. People already know they can quote identifiers and it only affects the case, so should we explicitly disallow the double-quotes? I don't see why, I guess. We certainly don't want to document the double-quotes though. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Thomas Lockhart writes: > Well, that would be how to distinguish them; we could define a new > token, say "QIDENT" to refer to quoted identifiers and leave "IDENT" for > the unquoted ones. Then a little work in gram.y should be enough to > finish the job. Is this confusion really worth it? What's wrong with being able to write: set something to "on"; -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Is this confusion really worth it?
I think everyone came to that conclusion after thinking awhile...
regards, tom lane
Surely for compatibility with existing apps, you'd need to allow both... Chris > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Thomas Lockhart > Sent: Tuesday, 26 February 2002 10:49 PM > To: PostgreSQL Hackers List > Subject: [HACKERS] quotes in SET grammar > > > Christopher's patch to fix docs regarding single- and double-quotes in > SET syntax got me looking at gram.y. It turns out that although we allow > lists of double-quoted strings in SET, we do not allow lists of > single-quoted strings (the latter should have been preferred afaik). And > although we allow single-quoted strings in SET TIME ZONE, we do not > allow double-quoted strings! So things seem inconsistant to me. > > Possible cases look like > > SET TIME ZONE 'pst8pdt'; > SET TIME ZONE "pst8pdt"; > SET DATESTYLE = "US","ISO"; > > Is there any objection to allowing both single- and double-quoted > strings in SET? Or should I remove the double-quoted variety altogether? > I've got patches for the former, but am willing to consider either > solution. afaik single-quoted strings would be sufficient to cover > users' expectations, and all cases are extentions to SQL9x syntax, which > only specifies SET TIME ZONE with a numeric offset. Comments? > > - Thomas > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
> Surely for compatibility with existing apps, you'd need to allow both...
For this particular case I would not think that is a consideration. In
SQL, the double quotes are used for identifiers only, and the single
quotes are used for strings etc. The latter is the category of input for
arguments to SET.
But it is not an issue for now; we will continue to support single
quotes and allow double quotes at least for 7.2.x.
- Thomas