Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases
Дата
Msg-id CAKFQuwa9CX11j5AZSp0Hk16wwW7474hhWHsCEGg1-dMsa4Mg+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-docs
On Fri, Nov 17, 2023 at 3:13 PM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Apr 27, 2018 at 01:47:49PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.5/static/sql-select.html
> Description:
>
> In the SELECT statement page the argument type of the (FOR SHARE/UPDATE) OF
> clause is listed to be a table_name. This is not *quite* accurate - it
> should reference the *alias* assigned to the table if one was given. The
> distinction is subtly important, as without this information the
> documentation implies that the choice of rows to lock can only be done
> per-table (i.e. that in a query mentioning the same table twice, *any*
> tuples being pulled from that table would be given the same treatment).
>
> But in fact postgres supports specifying the locking behaviour per-alias,
> which is a really powerful ability. And actually, trying to specify it by
> actual "table name" where an alias has been assigned won't work either.

The attached patch documents this.


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.

David J.

В списке pgsql-docs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: SELECT ... FOR UPDATE OF clause documentation implies use of table_names rather than aliases
Следующее
От: Erik Wienhold
Дата:
Сообщение: Re: T is a mandatory date time separator in RFC3339 but documentation states differently