Clarify how triggers relate to transactions
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/sql-createtrigger.html Description: https://www.postgresql.org/docs/current/sql-createtrigger.html mentions the word "transaction" only once, in reference specifically to constraint triggers: "They can be fired either at the end of the statement causing the triggering event, or at the end of the containing transaction; in the latter case they are said to be deferred." If I understand correctly, it would be helpful to add this sentence or a corrected version of it: "Triggers always execute in the same transaction as the triggering event, and if a trigger fails, the transaction is rolled back."
Re: Clarify how triggers relate to transactions
On Tue, 2021-04-27 at 14:26 +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/sql-createtrigger.html > Description: > > https://www.postgresql.org/docs/current/sql-createtrigger.html mentions the > word "transaction" only once, in reference specifically to constraint > triggers: "They can be fired either at the end of the statement causing the > triggering event, or at the end of the containing transaction; in the latter > case they are said to be deferred." > > If I understand correctly, it would be helpful to add this sentence or a > corrected version of it: "Triggers always execute in the same transaction as > the triggering event, and if a trigger fails, the transaction is rolled > back." Good idea in principle, but I'd put that information on https://www.postgresql.org/docs/current/trigger-definition.html Yours, Laurenz Albe
Re: Clarify how triggers relate to transactions
On Wed, 2021-04-28 at 13:18 -0400, Nathan Long wrote: > Gotcha. Where would I go to make the PR? You'd create a patch against Git master and send it to this mailing list or pgsql-hackers. If you don't want it to fall between the cracks, register in the next commitfest where it can undergo peer review. Yours, Laurenz Albe
Re: Clarify how triggers relate to transactions
Gotcha. Where would I go to make the PR? On Wed, Apr 28, 2021, 7:24 AM Laurenz Albe wrote: > On Tue, 2021-04-27 at 14:26 +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/13/sql-createtrigger.html > > Description: > > > > https://www.postgresql.org/docs/current/sql-createtrigger.html mentions > the > > word "transaction" only once, in reference specifically to constraint > > triggers: "They can be fired either at the end of the statement causing > the > > triggering event, or at the end of the containing transaction; in the > latter > > case they are said to be deferred." > > > > If I understand correctly, it would be helpful to add this sentence or a > > corrected version of it: "Triggers always execute in the same > transaction as > > the triggering event, and if a trigger fails, the transaction is rolled > > back." > > Good idea in principle, but I'd put that information on > https://www.postgresql.org/docs/current/trigger-definition.html > > Yours, > Laurenz Albe > >
Wrong type for the left argument of the operator "|/" and "||/" in chapter 9.3
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/functions-math.html Description: The left argument of the operator square root |/ and cube root ||/ in the current documentation is double precision. But to my experience that should also work on any numeric types including smallint, integer, bigint, real and numeric. I have tested it on both PostgreSQL server 12 and 13.
Re: Wrong type for the left argument of the operator "|/" and "||/" in chapter 9.3
PG Doc comments form writes: > The left argument of the operator square root |/ and cube root ||/ in the > current documentation is double precision. But to my experience that should > also work on any numeric types including smallint, integer, bigint, real and > numeric. I have tested it on both PostgreSQL server 12 and 13. The docs are correct. There is only one instance of these operators, and it takes double precision, as you can easily verify in psql: postgres=# \do |/ List of operators Schema | Name | Left arg type | Right arg type | Result type| Description +--+---+--+--+- pg_catalog | |/ | | double precision | double precision | square root (1 row) postgres=# \do ||/ List of operators Schema | Name | Left arg type | Right arg type | Result type| Description +--+---+--+--+- pg_catalog | ||/ | | double precision | double precision | cube root (1 row) The reason those other types are accepted is implicit casting, not that the operator takes something else than what's documented. But we're not going to clutter the function/operator tables with annotations about what other inputs can be accepted via casts --- it'd be bulky, repetitive, and probably more confusing than helpful. regards, tom lane
