Skip site navigation (1) Skip section navigation (2)

Re: quotes in SET grammar

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <thomas(at)fourpalms(dot)org>,PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: quotes in SET grammar
Date: 2002-02-26 17:56:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Thomas Lockhart <thomas(at)fourpalms(dot)org> writes:
> > Possible cases look like
> >   SET TIME ZONE 'pst8pdt';
> >   SET TIME ZONE "pst8pdt";
> > 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                        |
  pgman(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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-02-26 18:05:37
Subject: Re: COPY FROM is not 8bit clean
Previous:From: Bruce MomjianDate: 2002-02-26 17:45:52
Subject: Re: Implementation Proposal For Add Free Behind Capability

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group