Re: pg_get_*_ddl() needs a redesign

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, gonzalemario(at)gmail(dot)com, dbryan(dot)green(at)gmail(dot)com, euler(at)eulerto(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_*_ddl() needs a redesign
Date: 2026-09-11 16:27:57
Message-ID: CA+Tgmoa4bA4UgbqLA3ufTA=jYkA2GtE93BBgTS30EqGshwFUzA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 11, 2026 at 11:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Maybe --quote-all-identifiers should be the default? I don't think
> that we break old syntax "pretty regularly" in any other way.
> But that's a side point.

It's possible it's been less in recent years, but I feel like that's
just the most common way, like you know 50% of the total breakage or
something.

> I'm not quite convinced. But if that's really the case, I'm voting
> for "discard the feature". It's not useful enough to justify doubling
> the maintenance load associated with DDL reconstruction.

I think what really bothers me here is the chances of silent breakage,
which appear to be high. If it were somehow the case that adding a new
feature to some kind of DDL object, like a FLAVOR banana option to
CREATE TABLE, were likely to produce test failures until the
corresponding code was updated, I don't think that would be bad. It
would just be one more small step that everyone extending a DDL
command would have to do. But as it is, I don't think anything would
alert you to the oversight. That's likely to lead to a lot of future
headaches as we discover that things have been broken for years
without anybody noticing. Or maybe in the LLM era we'll just get a
flood of post-commit reports pointing out the problem. But that still
leads to us playing catch-up, which is not a good situation.

--
Robert Haas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-09-11 16:33:52 Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
Previous Message Nick Ivanov 2026-09-11 16:25:06 Re: Possible race condition in pg_basebackup