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

Re: quotes in SET grammar

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "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-27 01:28:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Surely for compatibility with existing apps, you'd need to allow both...


> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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";
> 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

In response to


pgsql-hackers by date

Next:From: Justin CliftDate: 2002-02-27 02:20:41
Subject: Experimental Feature development in PostgreSQL
Previous:From: Dann CorbitDate: 2002-02-27 00:39:56
Subject: Re: eWeek Poll: Which database is most critical to your

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