Re: Multiple TO version in ALTER EXTENSION UPDATE

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

In response to

Browse pgsql-hackers by date

  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