Re: some grammar refactoring

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: some grammar refactoring
Date: 2020-05-27 01:49:16
Message-ID: 21170.1590544156@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, May 26, 2020 at 4:28 AM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> Most utility commands don't have an intermediate parse analysis pass.
>> They just go straight from the grammar to the execution. Maybe that
>> could be rethought, but that's the way it is now.

> I think it can and should be rethought at some point.

The other problem is that the ones that do have explicit parse analysis
tend to be doing it at the wrong time. I've fixed some ALTER TABLE
problems by rearranging that, but we still have open bugs that are due
to this type of mistake, eg [1]. I agree that we need a rethink, and
we need it badly.

If this patch is changing when any parse-analysis-like actions happen,
then I would say that it needs very careful review --- much more than
the "refactoring" label would suggest. Maybe it's making things better,
or maybe it doesn't matter; but this area is a minefield.

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/16272-6e32da020e9a9381%40postgresql.org

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Isaac Morland 2020-05-27 02:56:39 Re: max_slot_wal_keep_size comment in postgresql.conf
Previous Message Thomas Munro 2020-05-27 01:46:54 Re: hash join error improvement (old)