Horton

Re: proposal: schema variables

Laurenz Albe <laurenz.albe@cybertec.at>

View thread
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Bruce Momjian <bruce@momjian.us>, Daniel Gustafsson <daniel@yesql.se>
Cc: Marcos Pegoraro <marcos@f10.com.br>, Pavel Stehule <pavel.stehule@gmail.com>, jian he <jian.universality@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-20T20:36:54Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> On Tue, May 20, 2025 at 08:47:36PM +0200, Daniel Gustafsson wrote:
> > > On 20 May 2025, at 18:39, Bruce Momjian <bruce@momjian.us> wrote:
> > > My only point is that we should only be using email lists for work that
> > > is being actively worked on to be added to community Postgres.  There
> > > has been talk of a trimmed-down version of this being applied, but I
> > > don't see any work in that direction.
> > > 
> > > This patch should be moved to a separate location where perhaps people
> > > can subscribe to updates when they are posted, perhaps github.
> > 
> > As a project with no roadmap governed by open forum consensus I don't think we
> > have any right to tell community members what they can or cannot work on here,
> > any technical discussion which conforms with our published policies should be
> > welcome.  If Pavel want's to continue rebasing his patchset here then he has,
> > IMHO, every right to do so.
> > 
> > Whether or not a committer will show interest at some point is another thing,
> > but we are seeing a very good role-model for taking responsibility for ones
> > work here at the very least =)
> 
> Well, we do have a right, e.g., we would not allow someone to repeatedly
> post patches for a Postgres extension we don't manage, or the jdbc
> driver.  I also don't think we would allow someone to continue posting
> patches for a feature we have decided to reject, and I think we have
> decided to reject the patch in in its current form.  I think we might
> accept a trimmed-down version, but I don't see the patch moving in that
> direction.
> 
> Now, of course, if I am the only one who feels this way, I can suppress
> these emails on my end.

In my opinion, this patch set is adding something that would be valuable to
have in core.

If no committer intends to pick it up and commit it, I think the proper
action would be to step up and reject the patch set, not complain about the
insistence of the author.

Yours,
Laurenz Albe