Re: Fwd: Re: proposal: schema variables
Gilles Darold <gilles@darold.net>
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
Le 17/01/2025 à 19:01, Bruce Momjian a écrit : > On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote: >> pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian <bruce@momjian.us> napsal: >> >> So this feature would be like global GUC variables, with permission >> control? >> >> + types and domain type check - holds data in binary form - there are not >> conversions binary, text >> + it is declared - so less space for misuse is there. Custom GUC are absolutely >> tolerant >> + it is a fully database object, only owner can alter it, and event triggers >> are supported, sinval >> + possibility to set mutability, default value > Okay, good summary. Now, can people give feedback that they would want > this committed to PostgreSQL? > For me, this is a must have. Not only because of the huge amount of time that we will save in migration to PostgreSQL (i know that this is not an argument) but because the only way we have to emulate such feature is to use custom configuration directives or a PL language that allows global variable. I have question almost every week on how to do that and the only answer I have is do this ugly pl/pgsql coding. It will be nice to have a feature to do that. Thanks Pavel and all involved in this implementation. -- Gilles Darold http://www.darold.net/