Re: [HACKERS] proposal: schema variables

Artur Zakirov <a.zakirov@postgrespro.ru>

From: Arthur Zakirov <a.zakirov@postgrespro.ru>

To: Pavel Stehule <pavel.stehule@gmail.com>

Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Fabien COELHO <coelho@cri.ensmp.fr>, Gilles Darold <gilles.darold@dalibo.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2018-09-21T19:46:18Z

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

On Wed, Sep 19, 2018 at 04:36:40PM +0200, Pavel Stehule wrote:
> ON COMMIT DROP is used only for temp variables (transaction or not
> transaction). The purpose is same like for tables. Sometimes you can to
> have object with shorter life than is session.
> 
> ON TRANSACTION END RESET has sense mainly for not transaction variables. I
> see two use cases.
> 
> 1. protect some sensitive data - on transaction end guaranteed reset and
> cleaning on end transaction. So you can be sure, so variable is not
> initialized (has default value), or you are inside transaction.
> 
> 2. automatic initialization - ON TRANSACTION END RESET ensure so variable
> is in init state for any transaction.
> 
> Both cases has sense for transaction or not transaction variables.
> 
> I am thinking so transaction life time for content has sense. Is cheaper to
> reset variable than drop it (what ON COMMIT DROP does)
> 
> What do you think?

Thanks, I understood the cases.

But I think there is more sense to use these options only with transactional
variables. It is more consistent and simple for me.

As a summary, it is 1 voice vs 1 voice :) So it is better to leave the
syntax as is without changes for now.

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company