Re: Re: proposal: schema variables
Bruce Momjian <bruce@momjian.us>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move WAL sequence code into its own file
- a87987cafca6 19 (unreleased) cited
-
Add ExplainState argument to pg_plan_query() and planner().
- c83ac02ec730 19 (unreleased) cited
-
Don't include access/htup_details.h in executor/tuptable.h
- 1a8b5b11e48a 19 (unreleased) cited
-
Refactor to avoid code duplication in transformPLAssignStmt.
- b0fb2c6aa5a4 19 (unreleased) cited
-
Avoid including commands/dbcommands.h in so many places
- 325fc0ab14d1 19 (unreleased) cited
-
Restrict psql meta-commands in plain-text dumps.
- 71ea0d679543 19 (unreleased) cited
-
Split func.sgml into more manageable pieces
- 4e23c9ef65ac 19 (unreleased) cited
-
Fix squashing algorithm for query texts
- 0f65f3eec478 18.0 cited
-
EXPLAIN: Always use two fractional digits for row counts.
- 95dbd827f2ed 18.0 cited
-
Preliminary refactoring of plpgsql expression construction.
- a654af21ae52 18.0 cited
-
plpgsql: pure parser and reentrant scanner
- 7b27f5fd36cb 18.0 cited
-
Add some sanity checks in executor for query ID reporting
- 24f520594809 18.0 cited
-
Fix misleading error message context
- 4af123ad45bd 18.0 cited
-
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited
On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote: > út 20. 5. 2025 v 18:39 odesílatel Bruce Momjian <bruce@momjian.us> napsal: > I sent a reduced version a few months ago - from 21 patches to 8 (and it can be > reduced to six if we postpone tools for detection ambiguity). > The timing was not perfect - the focus was and it is concentrated to finish > pg18. It was not clear to me that this patch set was being reduced to make it more likely it would be accepted? I thought it was the same patch set since 20??. > I am very sorry if this topic and patches bother anyone. I am afraid if I close > it to some personal github, it will not be visible, and I am sure this > feature is missing in Postgres. Today we have few workarounds. Some workarounds > are not available everywhere, some workarounds cannot > be used for security. With integrated solutions some scenarios can be done more > easily, more secure, faster, more comfortable. It is true, so > mentioned scenarios are not "hot" today. Stored procedures or RLS or migration > procedures from other databases are not extra common. But > who uses it, then he misses session variables. Understood. If people feel it is progressing toward acceptance, I certainly withdraw my objection and apologize. -- 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.