From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multiple TO version in ALTER EXTENSION UPDATE |
Date: | 2017-06-22 15:21:15 |
Message-ID: | 7263147A-78F4-4627-AC56-E65DD19384DD@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 22 Jun 2017, at 17:02, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>> While reading I noticed that we allow multiple TO <version> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2017-06-22 15:36:43 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |
Previous Message | Robert Haas | 2017-06-22 15:11:07 | Re: [psql] patch to fix ordering in words_after_create array |