Re: auto_explain.log_min_duration is limit for nested statement
On Mon, Nov 4, 2019 at 07:11:48AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/auto-explain.html > Description: > > Hello, > > I had problem with setup auto_explain.log_min_duration for COPY command on > table with triggers. I set minimum duration to '2s' but no plan logged > (duration of COPY command was above this limit). I thought that this > extension not working with COPY command. After some testing I investigate > that extension is working becouse duration limit is for nested statement > (query in trigger) not for base statement (COPY) - it will be fine write > somewere in documentation. COPY doesn't go through the optimizer, so there is nothing to explain, e.g., test=> EXPLAIN COPY test FROM STDIN; ERROR: syntax error at or near "COPY" LINE 1: EXPLAIN COPY test FROM STDIN; ^ -- 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: Small typo in func.sgml
On Thu, Nov 07, 2019 at 08:16:15AM +0900, Tatsuo Ishii wrote: > I think a new line is needed after . True that it is the usual pattern. -- Michael signature.asc Description: PGP signature
Small typo in func.sgml
I thinkk a new line is needed after . Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 28eb322f3f..6d82c9f0bd 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -12879,7 +12879,8 @@ table2-mapping . - JSON query functions and operators + + JSON query functions and operators pass the provided path expression to the path engine for evaluation. If the expression matches the queried JSON data, the corresponding SQL/JSON item is returned.
Re: Does 'instead of delete' trigger support modification of OLD
On Tue, Oct 29, 2019 at 05:54:36PM +0200, Eugen Konkov wrote: > Hi. > > This is not clear from doc, so I have asked on IRC too. > > from the DOC: https://www.postgresql.org/docs/current/trigger-definition.html > In the case of INSTEAD OF triggers, the possibly-modified row returned by > each trigger becomes the input to the next trigger > > I modify OLD row, thus I expect to get modified version when run next query: > > WITH t1 AS( delete from abc returning *) > select * from t1; > > fiddle: > https://dbfiddle.uk/?rdbms=postgres_12=637730305f66bf531794edb09a462c95 Wow, that is a very nice way to present the queries. > > https://www.postgresql.org/docs/current/trigger-definition.html > A row-level INSTEAD OF trigger should either return NULL to indicate that it > did not modify any data from the view's underlying base tables, > or it should return the view row that was passed in (the NEW row for INSERT > and UPDATE operations, or the OLD row for DELETE operations). > A nonnull return value is used to signal that the trigger performed the > necessary data modifications in the view. > This will cause the count of the number of rows affected by the command to be > incremented. For INSERT and UPDATE operations, the trigger may > modify the NEW row before returning it. This will change the data returned by > INSERT RETURNING or UPDATE RETURNING, > and is useful when the view will not show exactly the same data that was > provided. > > But I still does not understand. Doc explicitly do not prohibit modification > of OLD and has no examples for DELETE RETURNING case 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? 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. -- 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 + diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml new file mode 100644 index 67e1861..f62f420 *** a/doc/src/sgml/trigger.sgml --- b/doc/src/sgml/trigger.sgml *** *** 230,236 used to signal that the trigger performed the necessary data modifications in the view. This will cause the count of the number of rows affected by the command to be incremented. For ! INSERT and UPDATE operations, the trigger may modify the NEW row before returning it. This will change the data returned by INSERT RETURNING or UPDATE RETURNING, --- 230,236 used to signal that the trigger performed the necessary data modifications in the view. This will cause the count of the number of rows affected by the command to be incremented. For ! INSERT and UPDATE operations only, the trigger may modify the NEW row before returning it. This will change the data returned by INSERT RETURNING or UPDATE RETURNING,
Re: Adding a Column documentation is misleading
On Tuesday, November 5, 2019, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > 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'. > > A similar problem exists for removing a column, and other actions. > Chapter 5 is tutorial-like and uses actual meaningful names instead of syntax placeholders. I don’t really see a problem aside from maybe a different example name could be chosen. Making it column_name isn’t an improvement. David J.
Re: Why 'infinity' is not in range '[2019-01-02, infinity]'?
On Wed, Nov 6, 2019 at 12:15:17PM +0200, Eugen Konkov wrote: > !Specifying a missing bound as exclusive is automatically converted > !to inclusive, e.g., [,] is automatically converted > !to (,) > > Misspell? > > You say: >exclusive is automatically converted to inclusive > But then: >[,] is automatically converted to (,) > > which one is correct? My mistake. Thanks for finding that. Updated patch attached, plus I improved the second paragraph. -- 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 + diff --git a/doc/src/sgml/rangetypes.sgml b/doc/src/sgml/rangetypes.sgml new file mode 100644 index 3a034d9..b75fb3a *** a/doc/src/sgml/rangetypes.sgml --- b/doc/src/sgml/rangetypes.sgml *** SELECT isempty(numrange(1, 5)); *** 131,159 Infinite (Unbounded) Ranges !The lower bound of a range can be omitted, meaning that all points less !than the upper bound are included in the range. Likewise, if the upper !bound of the range is omitted, then all points greater than the lower bound !are included in the range. If both lower and upper bounds are omitted, all !values of the element type are considered to be in the range. ! ! ! !This is equivalent to considering that the lower bound is minus !infinity, or the upper bound is plus infinity, !respectively. But note that these infinite values are never values of !the range's element type, and can never be part of the range. (So there !is no such thing as an inclusive infinite bound if you try to !write one, it will automatically be converted to an exclusive bound.) !Also, some element types have a notion of infinity, but that !is just another value so far as the range type mechanisms are concerned. !For example, in timestamp ranges, [today,] means the same !thing as [today,). But [today,infinity] means !something different from [today,infinity) the latter !excludes the special timestamp value infinity. --- 131,156 Infinite (Unbounded) Ranges !The lower bound of a range can be omitted, meaning that all !values less than the upper bound are included in the range, e.g., !(,3]. Likewise, if the upper bound of the range !is omitted, then all values greater than the lower bound are included !in the range. If both lower and upper bounds are omitted, all values !of the element type are considered to be in the range. Specifying a !missing bound as inclusive is automatically converted to exclusive, !e.g., [,] is converted to (,). !You can think of these missing values as +/-infinity, but they are !special range type values and are considered to be beyond any range !element type's +/-infinity values. !Element types that have the notion of infinity can !use them as explicit bound values. For example, with timestamp !ranges, [today,infinity) excludes the special !timestamp value infinity, !while [today,infinity] include it, as does ![today,) and [today,].
Re: Adding a Column documentation is misleading
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. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Adding a Column documentation is misleading
The following documentation comment has been logged on the website: 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'. A similar problem exists for removing a column, and other actions.
