Re: Does 'instead of delete' trigger support modification of OLD
> I looked in the CREATE TRIGGER manual page and found this: > https://www.postgresql.org/docs/12/sql-createtrigger.html > If the trigger fires before or instead of the event, the trigger > can skip the operation for the current row, or change the row > being inserted (for INSERT and UPDATE operations only). > I don't see the "(for INSERT and UPDATE operations only)" language in > the main trigger documentation, > https://www.postgresql.org/docs/current/trigger-definition.html. I have > written the attached patch to fix that. Does that help? No. If we document that PG does not allow to modify OLD at instead of trigger, the we can not implement that. Probably we can put note that "currently modification of the trigger row for RETURNING is not implemented" > As far as allowing DELETE to modify the trigger row for RETURNING, I am > not sure how much work it would take to allow that, but it seems like it > is a valid requite, and if so, I can add it to the TODO list. Yes, Add please into TODO the feature to "allowing DELETE to modify the trigger row for RETURNING". Becuase, as I have described at first letter, without this the RETURNING rows **does not correspond actually deleted data** Thank you. -- Best regards, Eugen Konkov
Re: Does 'instead of delete' trigger support modification of OLD
Hello Eugen, Thursday, November 7, 2019, 11:20:32 AM, you wrote: >> I looked in the CREATE TRIGGER manual page and found this: >> https://www.postgresql.org/docs/12/sql-createtrigger.html >> If the trigger fires before or instead of the event, the trigger >> can skip the operation for the current row, or change the row >> being inserted (for INSERT and UPDATE operations only). >> I don't see the "(for INSERT and UPDATE operations only)" language in >> the main trigger documentation, >> https://www.postgresql.org/docs/current/trigger-definition.html. I have >> written the attached patch to fix that. Does that help? > No. If we document that PG does not allow to modify OLD at instead > of trigger, the we can not implement that. Probably we can put note > that "currently modification of the trigger row for RETURNING is not > implemented" sorry, typo. Please read: "currently modification of the trigger row for DELETE RETURNING is notimplemented" >> As far as allowing DELETE to modify the trigger row for RETURNING, I am >> not sure how much work it would take to allow that, but it seems like it >> is a valid requite, and if so, I can add it to the TODO list. > Yes, Add please into TODO the feature to "allowing DELETE to modify the > trigger row > for RETURNING". Becuase, as I have described at first letter, without > this the RETURNING rows **does not correspond actually deleted data** > Thank you. -- Best regards, Eugen Konkov
Nit: "Immutable" should be "pure"
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/sql-createindex.html Description: The adjective "immutable" describing the functions and operators used in an index (see two occurrences in doc snippet below) is incorrect and should be replaced with "pure". Both "pure" and "immutable" are in popular lexicon now because of the interest in functional programming, so conflating the two can happen, but the word immutable applies to data and pure applies to functions. See https://en.wikipedia.org/wiki/Pure_function. From the CREATE INDEX doc: All functions and operators used in an index definition must be “immutable”, that is, their results must depend only on their arguments and never on any outside influence (such as the contents of another table or the current time). This restriction ensures that the behavior of the index is well-defined. To use a user-defined function in an index expression or WHERE clause, remember to mark the function immutable when you create it.
The word "virgin" used incorrectly and probably better off replaced
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/manage-ag-templatedbs.html Description: The use of the word virgin as an adjective is incorrect here and also an anachronism. It is better off replaced with the word pristine - quotes unnecessary. Note the word virgin appears in another page of the documentation (a search will find it).
Re: The word "virgin" used incorrectly and probably better off replaced
On 2019-Nov-07, PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/12/manage-ag-templatedbs.html > Description: > > The use of the word virgin as an adjective is incorrect here and also an > anachronism. It is better off replaced with the word pristine - quotes > unnecessary. Note the word virgin appears in another page of the > documentation (a search will find it). Just because a word has sexual connotations does not imply that it doesn't have non-sexual meanings. Merriam-Webster lists https://www.merriam-webster.com/dictionary/virgin 2: FRESH, UNSPOILED specifically : not altered by human activity 6: free of impurity or stain : UNSULLIED which seems to apply well to all cases at hand. Also: First Known Use of virgin Noun: 13th century, in the meaning defined at sense 2a Adjective: 14th century, in the meaning defined at sense 6 History and Etymology for virgin Noun: Middle English, from Anglo-French virgine, from Latin virgin-, virgo young woman, virgin That said, in two of the three phrases where the word appears, the quoted adjective adds no value. We could remove the quoted word entirely in all three places and nothing would be lost. But if we do that, then the third occurrence of the word would become inintelligible: "This is particularly handy when restoring a pg_dump dump: the dump script should be restored in a virgin database to ensure that one recreates the correct contents of the dumped database, without conflicting with objects that might have been added to template1 later on." because we have not explained what a "virgin database" is. We could say "empty", which seems better suited than both "virgin" and "pristine" anyway. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Small typo in func.sgml
Tatsuo Ishii writes: > I thinkk a new line is needed after . > - JSON query functions and operators > + > + JSON query functions and operators It doesn't really make any difference, I believe. I agree it's neater with the newline, but I wouldn't bother changing it unless you're making some other nearby change. (There are actually instances of this in quite a few places in our docs, if memory serves. I think somebody uses, or used, an editor that tended to remove newlines in that context.) regards, tom lane
Re: Nit: "Immutable" should be "pure"
On Thu, Nov 7, 2019 at 02:17:58PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/sql-createindex.html
> Description:
>
> The adjective "immutable" describing the functions and operators used in an
> index (see two occurrences in doc snippet below) is incorrect and should be
> replaced with "pure". Both "pure" and "immutable" are in popular lexicon now
> because of the interest in functional programming, so conflating the two can
> happen, but the word immutable applies to data and pure applies to
> functions. See https://en.wikipedia.org/wiki/Pure_function.
>
> From the CREATE INDEX doc:
> All functions and operators used in an index definition must be “immutable”,
> that is, their results must depend only on their arguments and never on any
> outside influence (such as the contents of another table or the current
> time). This restriction ensures that the behavior of the index is
> well-defined. To use a user-defined function in an index expression or WHERE
> clause, remember to mark the function immutable when you create it.
Well, we use IMMUTABLE as an option to CREATE FUNCTION so I don't see
how we can realign to the new word meanings without a lot of confusion:
CREATE [ OR REPLACE ] FUNCTION
name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = }
default_expr ] [, ...] ] )
[ RETURNS rettype
| RETURNS TABLE ( column_name column_type [, ...] ) ]
{ LANGUAGE lang_name
| TRANSFORM { FOR TYPE type_name } [, ... ]
| WINDOW
| IMMUTABLE | STABLE | VOLATILE | [ NOT ] LEAKPROOF
^
I think the best we can do is to mention that IMMUTABLE functions mean
pure, but I am not sure there is even enough demand for that, vs.
confusing people.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Re: Nit: "Immutable" should be "pure"
Bruce Momjian writes: > On Thu, Nov 7, 2019 at 02:17:58PM +, PG Doc comments form wrote: >> The adjective "immutable" describing the functions and operators used in an >> index (see two occurrences in doc snippet below) is incorrect and should be >> replaced with "pure". > I think the best we can do is to mention that IMMUTABLE functions mean > pure, but I am not sure there is even enough demand for that, vs. > confusing people. Yeah. I don't think this terminology is nearly as universal as the OP believes, so I don't feel a need to change anything. If we adopt Corey's proposal to create a glossary [1], there'd be room for a parenthetical comment like "(In some circles, "pure" is the preferred term for this function property.)" in the glossary entry for "immutable". I suspect it won't be the only entry that needs cross-references to other terminology. regards, tom lane [1] https://commitfest.postgresql.org/25/2305/
Re: The word "virgin" used incorrectly and probably better off replaced
> On 7 Nov 2019, at 16:03, Alvaro Herrera wrote: > because we have not explained what a "virgin database" is. I think this is the key observation. > We could say "empty", which seems better suited than both "virgin" and > "pristine" anyway. empty is a lot better, but still isn't conveying the state of the database without there being room for interpretation. (My grasp of the english language isn't enough to suggest a better alternative however). cheers ./daniel
Re: Adding a Column documentation is misleading
On 07/11/2019 02:13, Alvaro Herrera wrote: On 2019-Nov-06, PG Doc comments form wrote: Page: https://www.postgresql.org/docs/12/ddl-alter.html Description: In 5.6.1. Adding a Column, there is a kind of example 'ALTER TABLE products ADD COLUMN description text;' The words 'description' and 'text' are misleading -- as according to the formal documentation of the SQL command (https://www.postgresql.org/docs/12/sql-altertable.html), they should be 'column_name' and 'data_type'. Well, it's an example, so "description" is the column name and "text" is its data type. If you had a table called products, you could run that command and it would work just fine (assuming you don't already have a column called description, doh). Maybe the example could be made clearer by using some other column name and some other data type, so that they don't resemble english prose or keywords. Maybe "alter table cities add column year_founded integer". Do you want to propose something better than that? A similar problem exists for removing a column, and other actions. Let's hear your proposed changes. Now it's explained, it is obvious! Sorry, for the noise. Cheers, Gavin
Re: Nit: "Immutable" should be "pure"
Thanks for the feedback folks. I had not seen the IMMUTABLE argument to CREATE FUNCTION and realize this change is too expensive. This probably will not be the last you hear on this since pureness and immutability are all the rage in development circles. > On Nov 7, 2019, at 12:38 PM, Tom Lane wrote: > > Bruce Momjian writes: >> On Thu, Nov 7, 2019 at 02:17:58PM +, PG Doc comments form wrote: >>> The adjective "immutable" describing the functions and operators used in an >>> index (see two occurrences in doc snippet below) is incorrect and should be >>> replaced with "pure". > >> I think the best we can do is to mention that IMMUTABLE functions mean >> pure, but I am not sure there is even enough demand for that, vs. >> confusing people. > > Yeah. I don't think this terminology is nearly as universal > as the OP believes, so I don't feel a need to change anything. > > If we adopt Corey's proposal to create a glossary [1], there'd be > room for a parenthetical comment like "(In some circles, "pure" is the > preferred term for this function property.)" in the glossary entry for > "immutable". I suspect it won't be the only entry that needs > cross-references to other terminology. > > regards, tom lane > > [1] https://commitfest.postgresql.org/25/2305/
Re: Does 'instead of delete' trigger support modification of OLD
On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote: > Hello Eugen, > > Thursday, November 7, 2019, 11:20:32 AM, you wrote: > > >> I looked in the CREATE TRIGGER manual page and found this: > > >> https://www.postgresql.org/docs/12/sql-createtrigger.html > >> If the trigger fires before or instead of the event, the trigger > >> can skip the operation for the current row, or change the row > >> being inserted (for INSERT and UPDATE operations only). > > >> I don't see the "(for INSERT and UPDATE operations only)" language in > >> the main trigger documentation, > >> https://www.postgresql.org/docs/current/trigger-definition.html. I have > >> written the attached patch to fix that. Does that help? > > > No. If we document that PG does not allow to modify OLD at instead > > of trigger, the we can not implement that. Probably we can put note > > that "currently modification of the trigger row for RETURNING is not > > implemented" > > sorry, typo. Please read: > "currently modification of the trigger row for DELETE RETURNING is > notimplemented" In looking at the existing docs, the bullet above the quoted text says: For row-level INSERT and UPDATE triggers only, the returned row becomes the row that will be inserted or will replace the row being updated. This allows the trigger function to modify the row being inserted or updated. First, notice "only", which was missing from the later sentence: For INSERT and UPDATE operations [only], the trigger may modify the NEW row before returning it. which I have now added with my applied patch to all supported releases. The major use of modifying NEW is to modify the data that goes into the database, and its use to modify data seen by later executed triggers, or by RETURNING, is only a side-effect of its primary purpose. Therefore, it is not surprising that, since DELETE does not modify any data, just removes it, that the modification of OLD to appear in later triggers or RETURNING is not supported. > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am > >> not sure how much work it would take to allow that, but it seems like it > >> is a valid requite, and if so, I can add it to the TODO list. > > > Yes, Add please into TODO the feature to "allowing DELETE to modify the > > trigger row > > for RETURNING". Becuase, as I have described at first letter, without > > this the RETURNING rows **does not correspond actually deleted data** > > > Thank you. I have added a TODO item: Allow DELETE triggers to modify rows, for use by RETURNING -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: The word "virgin" used incorrectly and probably better off replaced
On Thu, Nov 7, 2019 at 07:55:22PM +0100, Daniel Gustafsson wrote: > > On 7 Nov 2019, at 16:03, Alvaro Herrera wrote: > > > because we have not explained what a "virgin database" is. > > I think this is the key observation. > > > We could say "empty", which seems better suited than both "virgin" and > > "pristine" anyway. > > empty is a lot better, but still isn't conveying the state of the database > without there being room for interpretation. (My grasp of the english > language > isn't enough to suggest a better alternative however). I am thinking "pristine" would be a good word here. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: The word "virgin" used incorrectly and probably better off replaced
On 2019-Nov-07, Bruce Momjian wrote: > On Thu, Nov 7, 2019 at 07:55:22PM +0100, Daniel Gustafsson wrote: > > > On 7 Nov 2019, at 16:03, Alvaro Herrera wrote: > > > We could say "empty", which seems better suited than both "virgin" and > > > "pristine" anyway. > > > > empty is a lot better, but still isn't conveying the state of the database > > without there being room for interpretation. (My grasp of the english > > language > > isn't enough to suggest a better alternative however). > > I am thinking "pristine" would be a good word here. But you would have to explain that a database created as a copy of template1 may somehow not be pristine. Maybe we should just use a phrase that describes what we mean, something like "a database that doesn't contain objects other than default system ones." -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Does 'instead of delete' trigger support modification of OLD
On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote: > On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote: > > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am > > >> not sure how much work it would take to allow that, but it seems like it > > >> is a valid requite, and if so, I can add it to the TODO list. > > > > > Yes, Add please into TODO the feature to "allowing DELETE to modify the > > > trigger row > > > for RETURNING". Becuase, as I have described at first letter, without > > > this the RETURNING rows **does not correspond actually deleted data** > > > > > Thank you. > > I have added a TODO item: > > Allow DELETE triggers to modify rows, for use by RETURNING Thinking some more on this, I now don't think a TODO makes sense, so I have removed it. Triggers are designed to check and modify input data, and since DELETE has no input data, it makes no sense. In the attached SQL script, you can see that only the BEFORE INSERT trigger fires, so there is no way even with INSERT to change what is passed after the write to RETURNING. What you can do is to modify the returning expression, which is what I have done for the last query --- hopefully that will help you. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + trigtest.sql Description: application/sql
Re: wal_sender_timeout / wal_receiver_timeout - seconds or milliseconds?
On Wed, Nov 6, 2019 at 04:41:10PM +0900, Michael Paquier wrote: > On Tue, Nov 05, 2019 at 10:21:38AM -0500, Bruce Momjian wrote: > > Ugh, the "if no unit specified" is true of all the settings. Should we > > make that clearer in a more central location. > > Hmm. Are you thinking about a new single location in the docs? I > would be afraid to have something like that rot easily as users would > most likely only read the description of each individual parameter > rather than travel across multiple sections. Also, if you look at > guc.c the default units of each parameter are a case-by-case. > log_rotation_age uses minutes for example, autovacuum_naptime seconds, > etc. Right. I am just asking if we need to do this for _every_ case where the default value doesn't match the default _units_, or if we need to have some kind of central notification. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: The word "virgin" used incorrectly and probably better off replaced
On Thu, Nov 7, 2019 at 06:50:10PM -0300, Alvaro Herrera wrote: > On 2019-Nov-07, Bruce Momjian wrote: > > > On Thu, Nov 7, 2019 at 07:55:22PM +0100, Daniel Gustafsson wrote: > > > > On 7 Nov 2019, at 16:03, Alvaro Herrera > > > > wrote: > > > > > We could say "empty", which seems better suited than both "virgin" and > > > > "pristine" anyway. > > > > > > empty is a lot better, but still isn't conveying the state of the database > > > without there being room for interpretation. (My grasp of the english > > > language > > > isn't enough to suggest a better alternative however). > > > > I am thinking "pristine" would be a good word here. > > But you would have to explain that a database created as a copy of > template1 may somehow not be pristine. Maybe we should just use a > phrase that describes what we mean, something like "a database that > doesn't contain objects other than default system ones." True. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: wal_sender_timeout / wal_receiver_timeout - seconds or milliseconds?
On Thu, Nov 07, 2019 at 05:36:17PM -0500, Bruce Momjian wrote: > Right. I am just asking if we need to do this for _every_ case where > the default value doesn't match the default _units_, or if we need to > have some kind of central notification. Doing it for all places where it matters makes sense to me, aka in the description of the docs for each parameter, and perhaps add a note in postgresql.conf.sample. I am still not sure what you mean with a central notification though, like a separate section in the docs? -- Michael signature.asc Description: PGP signature
