Multiple TO version in ALTER EXTENSION UPDATE
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36370psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 07:34 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36370_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36370_1 && git checkout t36370_1Patchset v1 (message #1) is on t36370_1
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).
cheers ./daniel
On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson <daniel@yesql.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.
--
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
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson <daniel@yesql.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, 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
On 22 Jun 2017, at 17:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson <daniel@yesql.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers