Horton

Re: proposal: schema variables

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Daniel Gustafsson <daniel@yesql.se>, Marcos Pegoraro <marcos@f10.com.br>, 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-21T20:41:38Z
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 Wed, May 21, 2025 at 07:15:27AM +0200, Pavel Stehule wrote:
> út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian <bruce@momjian.us> napsal:
>     > 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.
> 
>     Are you saying I should not complain until we have officially rejected
>     the patch set?  If we officially reject it, the patch author would no
>     longer post it?
> 
> I'll respect committers. I really don't want to worry people in the community.
> It is not my way, and I am sorry.

I realize I am being the bad guy by asking these questions, but I don't
think it is good for the project to get distracted with a feature that
isn't progressing, and it is unpleasant for an author to keep working on
something with no clear direction from the community.  I am happy to
learn that progress is being made.

I see this feature being first proposed in 2012:

	https://www.postgresql.org/message-id/flat/CAFj8pRDdk_4E8HiffbVOfk97iR%2BSLFoZpRT4D2nTE89YU-hQrg%40mail.gmail.com

and the first question was:

	I don't really see what we can do with this that we can't do
	without this.

Now, I think we have answered that question, and gotten closer to seeing
the complexities of adding this feature.

I am asking that, given its age, we more clearly direct this patch,
either toward completion or rejection.

> I think this is an important feature - for some group of developers, and then I
> push my energy and time for this.
> On the other hand, I accept that there is a lot of work that is important for a
> wider group of users. So it is. Unfortunately,
> without parser's hooks this feature cannot be implemented as an extension. But
> parser's hooks was proposed,
> and rejected, so there is no other possibility, how to do it. More -
> implementation of this feature as an extension is not
> best way.

I will reply to this in my next email.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.