On Fri, Nov 17, 2023 at 3:13 PM Bruce Momjian <br...@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.
