Re: proposal: schema variables
Pavel Stehule <pavel.stehule@gmail.com>
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
Hi
st 20. 11. 2024 v 14:29 odesílatel Marcos Pegoraro <marcos@f10.com.br>
napsal:
> Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule <
> pavel.stehule@gmail.com> escreveu:
>
>> I wrote POC of VARIABLE(varname) syntax support
>>
>
> Not related with POC of VARIABLE but seeing your patches ...
>
> Wouldn't it be better to use just one syntax and message for what to do ON
> COMMIT ?
>
> When creating a new variable you use
> CREATE VARIABLE ... ON COMMIT DROP | ON TRANSACTION END RESET
>
> On PSQL \dV+ you show
> Transactional end action
>
> Maybe all them could be just ON COMMIT
> CREATE VARIABLE ... [ON COMMIT {NO ACTION, DROP, RESET}] and \dV+ just "on
> commit" on title column
>
ON COMMIT DROP is related to temporary objects. In this case, you don't
need to think about ROLLBACK, because in this case, the temp objects are
removed implicitly.
ON TRANSACTION END RESET can be used for non temporary objects too. So this
is a little bit of a different feature. But the reset is executed if the
transaction is ended by ROLLBACK too. So using a syntax just ON COMMIT can
be a little bit messy. TRANSACTION END is more intuitive, I think. If I
remember there was a proposal ON COMMIT OR ROLLBACK, but I think
TRANSACTION END is better and more intuitive, and better describes what is
implemented. I can imagine to support clauses ON COMMIT RESET or ON
ROLLBACK RESET that can be used independently, but for this time, I don't
want to increase a complexity now - reset is just at transaction end
without dependency if the transaction was committed or rollbacked.
Regards
Pavel
> regards
> Marcos
>