quotes in SET grammar

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, Pennsylvania 19026

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.

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

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

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

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, Pennsylvania 19026

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, Pennsylvania 19026

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

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