Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases
On Mon, Nov 20, 2023 at 8:16 PM Bruce Momjian wrote: > On Mon, Nov 20, 2023 at 07:19:39PM -0700, David G. Johnston wrote: > > The placement in the numbered listing section feels wrong, I am OK with > > the wording. It should be down in the clause details. > > > > FOR lock_strength [ OF from_reference [, ...] ] [ NOWAIT | SKIP LOCKED > ] -- > > need to change this spot to match > > > > where lock_strength can be one of > > > > [...] > > > > + and from_reference must be a table alias or non-hidden table_name > referenced > > in the FROM clause. > > > > For more information on each [...] > > Ah, good point. I was searching for "FOR UPDATE" so I missed that > section; updated patch attached. > > WFM. Thanks! David J.
Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases
On Mon, Nov 20, 2023 at 07:19:39PM -0700, David G. Johnston wrote:
> The placement in the numbered listing section feels wrong, I am OK with
> the wording. It should be down in the clause details.
>
> FOR lock_strength [ OF from_reference [, ...] ] [ NOWAIT | SKIP LOCKED ] --
> need to change this spot to match
>
> where lock_strength can be one of
>
> [...]
>
> + and from_reference must be a table alias or non-hidden table_name referenced
> in the FROM clause.
>
> For more information on each [...]
Ah, good point. I was searching for "FOR UPDATE" so I missed that
section; updated patch attached.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 227ba1993b..9917df7839 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -45,7 +45,7 @@ SELECT [ ALL | DISTINCT [ ON ( expressioncount | ALL } ]
[ OFFSET start [ ROW | ROWS ] ]
[ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES } ]
-[ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF table_name [, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ]
+[ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF from_reference [, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ]
where from_item can be one of:
@@ -1577,7 +1577,7 @@ FETCH { FIRST | NEXT } [ count ] {
The locking clause has the general form
-FOR lock_strength [ OF table_name [, ...] ] [ NOWAIT | SKIP LOCKED ]
+FOR lock_strength [ OF from_reference [, ...] ] [ NOWAIT | SKIP LOCKED ]
where lock_strength can be one of
@@ -1591,8 +1591,11 @@ KEY SHARE
-For more information on each row-level lock mode, refer to
-.
+from_reference must be a
+table alias or non-hidden
+table_name referenced
+in the FROM clause. For more information on each
+row-level lock mode, refer to .
Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases
On Mon, Nov 20, 2023 at 7:04 PM Bruce Momjian wrote: > On Fri, Nov 17, 2023 at 03:44:04PM -0700, David G. Johnston wrote: > > I don't like this particular solution to the stated complaint. When a > FROM > > entry has an alias it must be referenced via that alias anywhere it is > > referenced in the query - and indeed it is an error to not write the > alias in > > your example. It is not an improvement to write [ table_name | alias ] > in our > > syntax to try and demonstrate this requirement. If we do want to not say > > "table_name" I suggest we say instead "from_reference" and then just > define > > what that means (i.e., an unaliased table name or an alias in the > sibling FROM > > clause attached to this level of the query). I like this better anyway > on the > > grounds that the thing being referenced can be a subquery or a view as > well as > > a table. > > Okay, how is the attached patch? > > The placement in the numbered listing section feels wrong, I am OK with the wording. It should be down in the clause details. FOR lock_strength [ OF from_reference [, ...] ] [ NOWAIT | SKIP LOCKED ] -- need to change this spot to match where lock_strength can be one of [...] + and from_reference must be a table alias or non-hidden table_name referenced in the FROM clause. For more information on each [...] David J.
Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases
On Fri, Nov 17, 2023 at 03:44:04PM -0700, David G. Johnston wrote:
> I don't like this particular solution to the stated complaint. When a FROM
> entry has an alias it must be referenced via that alias anywhere it is
> referenced in the query - and indeed it is an error to not write the alias in
> your example. It is not an improvement to write [ table_name | alias ] in our
> syntax to try and demonstrate this requirement. If we do want to not say
> "table_name" I suggest we say instead "from_reference" and then just define
> what that means (i.e., an unaliased table name or an alias in the sibling FROM
> clause attached to this level of the query). I like this better anyway on the
> grounds that the thing being referenced can be a subquery or a view as well as
> a table.
Okay, how is the attached patch?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 227ba1993b..c98ee8f7ee 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -45,7 +45,7 @@ SELECT [ ALL | DISTINCT [ ON ( expressioncount | ALL } ]
[ OFFSET start [ ROW | ROWS ] ]
[ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES } ]
-[ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF table_name [, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ]
+[ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF from_reference [, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ]
where from_item can be one of:
@@ -202,7 +202,11 @@ TABLE [ ONLY ] table_name [ * ]
is specified, the
SELECT statement locks the selected rows
against concurrent updates. (See
- below.)
+ below.) from_reference must be a table
+ alias or non-hidden
+ table_name referenced
+ in the FROM clause.
Re: T is a mandatory date time separator in RFC3339 but documentation states differently
On 2023-11-20 08:14 +0100, Peter Eisentraut wrote: > On 19.11.23 21:34, Erik Wienhold wrote: > > * Making explicit references to ISO 8601:2004 where section numbers are > >referenced. Mostly in source comments but also a couple of places in > >the docs. This is about avoiding confusion as ISO 8601:2019 has been > >published since then, with different section numbers[1]. The pre-2004 > >editions also have different section numbers. References to general > >ISO 8601 concepts (e.g. week numbers) are left unchanged because those > >are not tied to any particular edition. > > Maybe we should change the references to the 2019 edition instead? I wouldn't do that without knowing the full text of the standard. Maybe I can eyeball which 2004 sections map to 2019 sections but I wouldn't be confident in that. Also 8601:2019 removed 24:00 as midnight for some reason but it is allowed again with an ammendment from 2022. Not sure what else changed besides the "main changes" summarized in the foreword of [1]. And I can't find the 2022 ammendment on iso.org. [1] https://www.iso.org/obp/ui/en/#iso:std:iso:8601:-1:ed-1:v1:en -- Erik
