Re: PGQ catalog representation and pg_dump support

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, rmt(at)lists(dot)postgresql(dot)org
Subject: Re: PGQ catalog representation and pg_dump support
Date: 2026-09-07 19:34:28
Message-ID: 2c117e19-4736-4486-89b4-e66c56d1bb12@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.09.26 23:32, Robert Haas wrote:
> On Thu, Sep 3, 2026 at 4:53 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> On 02.09.26 21:29, Melanie Plageman wrote:
>>> As such, unless we are misunderstanding something about the
>>> discussion, we feel it would be better to revert this in 19. That
>>> would take off the time pressure now and would make it easier to fix
>>> these things properly in 20 without having to be burdened by backwards
>>> compatibility and backpatching.
>>
>> Ok, let's do it.
>>
>> For clarification: Revert from REL_19_STABLE only, or also from master?
>
> IMHO, this needs enough rework that it should come out of both.

done

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidar Imamov 2026-09-07 19:59:22 Re: BgBufferSync(): clarification about reusable_buffers variable
Previous Message Bharath Rupireddy 2026-09-07 19:15:00 Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start