Re: [HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

2017-06-22 Thread Daniel Gustafsson
> On 22 Jun 2017, at 17:02, Tom Lane  wrote:
> 
> Robert Haas  writes:
>> On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson  wrote:
>>> While reading I noticed that we allow multiple TO  in ALTER 
>>> EXTENSION
>>> UPDATE, and defer throwing a syntax error until command processing.  Is 
>>> there a
>>> reason for deferring and not handling it in gram.y directly as in the 
>>> attached
>>> patch since it is in fact a syntax error?  It yields a different error 
>>> message
>>> to the user, but makes for easier to read code (IMH-and-biased-O).
> 
>> I think the idea of the current implementation was probably that the
>> grammar should leave room to support multiple options in arbitrary
>> order at that point in the syntax.  I'm not sure whether that's
>> something we'll ever actually need, or not.
> 
> It certainly seems plausible to me that we might someday grow additional
> options to control the UPDATE,

Fair enough, I was mainly curious about the reasoning, future proofing support
for additional options makes perfect sense.

> so I'm inclined to reject this patch.

I completely agree, I was using the patch to illustrate my question but wasn’t
very clear about that.

Thanks!

cheers ./daniel

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

2017-06-22 Thread Tom Lane
Robert Haas  writes:
> On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson  wrote:
>> While reading I noticed that we allow multiple TO  in ALTER 
>> EXTENSION
>> UPDATE, and defer throwing a syntax error until command processing.  Is 
>> there a
>> reason for deferring and not handling it in gram.y directly as in the 
>> attached
>> patch since it is in fact a syntax error?  It yields a different error 
>> message
>> to the user, but makes for easier to read code (IMH-and-biased-O).

> I think the idea of the current implementation was probably that the
> grammar should leave room to support multiple options in arbitrary
> order at that point in the syntax.  I'm not sure whether that's
> something we'll ever actually need, or not.

It certainly seems plausible to me that we might someday grow additional
options to control the UPDATE, so I'm inclined to reject this patch.
If it were saving a meaningful amount of grammar code, I might think
differently, but it's not really.  And it's not like we don't use the
same grammar pattern in lots of other places.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

2017-06-22 Thread Robert Haas
On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson  wrote:
> While reading I noticed that we allow multiple TO  in ALTER EXTENSION
> UPDATE, and defer throwing a syntax error until command processing.  Is there 
> a
> reason for deferring and not handling it in gram.y directly as in the attached
> patch since it is in fact a syntax error?  It yields a different error message
> to the user, but makes for easier to read code (IMH-and-biased-O).

I think the idea of the current implementation was probably that the
grammar should leave room to support multiple options in arbitrary
order at that point in the syntax.  I'm not sure whether that's
something we'll ever actually need, or not.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

2017-03-29 Thread Daniel Gustafsson
While reading I noticed that we allow multiple TO  in ALTER EXTENSION
UPDATE, and defer throwing a syntax error until command processing.  Is there a
reason for deferring and not handling it in gram.y directly as in the attached
patch since it is in fact a syntax error?  It yields a different error message
to the user, but makes for easier to read code (IMH-and-biased-O).

cheers ./daniel



extension_update_syntax.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers