| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 05:26:49 |
| Message-ID: | 20260911052649.e3.noahmisch@microsoft.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 11, 2026 at 12:19:15AM -0400, Robert Haas wrote:
> On Thu, Sep 10, 2026 at 12:00 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > Going forward, feel free to add me to the To: line of a mailing list post and
> > explicitly ask me for my guess about the project's overall prognosis, likely
> > ways of failing, etc. My guess may be brief and/or wrong, but I'll provide
> > one.
>
> I don't think this is how this mailing list works. The volume is
> overwhelming for me, too, but patch authors aren't obliged to cc
> anyone specifially.
To clarify, that text was me offering Andrew a new option, not suggesting that
he has any new duty.
> > When it's four months after feature freeze and I find non-subtle, unreported
> > defects in the feature, the development process wasn't adequate for the
> > subject matter. To be transparent, observing this outcome changed my view of
> > code duplication. Duplication was always a smell, but it seemed like a
> > plausible compromise tactic in 2025. Now I find the duplication gave wrong
> > code too much place to hide.
>
> I think we would do well to confine all of our present conversations,
> insofar as it is possible to do so, to whether any given feature
> contains defects incompatible with shipping it.
The defects are the reason not to ship this implementation. One of those
defects, the inability to restore in dependency order, cannot be fixed without
redesigning the current SQL-facing API. That is the reason not to ship this
design. See my original post of this thread for details.
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | shveta malik | 2026-09-11 05:11:21 | Re: Crashes on a partition whose concurrent detach never finished |