Re: proposal: schema variables

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Bruce Momjian <bruce@momjian.us>
Cc: Marcos Pegoraro <marcos@f10.com.br>, Pavel Stehule <pavel.stehule@gmail.com>, jian he <jian.universality@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, 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-20T18:47:36Z
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 20 May 2025, at 18:39, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
>> Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian <bruce@momjian.us>
>> escreveu:
>> 
>>    I will again ask why this patch set is being reposted when there is no
>>    plan to apply it to git master
>> 
>> Too bad. I would love to have this functionality, from the user's point of view
>> there are problems where it would solve them wonderfully. I don't know
>> technically of what prevents it from being natively on core, but it would be
>> great, it would definitely be.
> 
> 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 =)

--
Daniel Gustafsson