Re: Re: [HACKERS] proposal: schema variables

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>

To: David Steele <david@pgmasters.net>

Cc: Pavel Stehule <pavel.stehule@gmail.com>, Artur Zakirov <a.zakirov@postgrespro.ru>, Dean Rasheed <dean.a.rasheed@gmail.com>, Gilles Darold <gilles.darold@dalibo.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

Date: 2019-03-07T08:10:47Z

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 →

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

Hello David,

> This patch hasn't receive any review in a while and I'm not sure if that's 
> because nobody is interested or the reviewers think it does not need any more 
> review.
>
> It seems to me that this patch as implemented does not quite satisfy any one.
>
> I think we need to hear something from the reviewers soon or I'll push this 
> patch to PG13 as Andres recommends [1].

I have discussed the feature extensively with Pavel on the initial thread.

My strong opinion based on the underlying use case is that it that such 
session variables should be transactional by default, and Pavel strong 
opinion is that they should not, to be closer to Oracle comparable 
feature.

According to the documentation, the current implementation does provide a 
transactional feature. However, it is not the default behavior, so I'm in 
disagreement on a key feature, although I do really appreciate that Pavel
implemented the transactional behavior.

Otherwise, ISTM that they could be named "SESSION VARIABLE" because the 
variable only exists in memory, in a session, and we could thing of adding 
other kind of variables later on.

I do intend to review it in depth when it is transactional by default.

Anyway, the patch is non trivial and very large, so targetting v12 now is 
indeed out of reach.

-- 
Fabien.