Re: pgsql: Doc: improve documentation about composite-value usage. - Mailing list pgsql-committers

From David G. Johnston
Subject Re: pgsql: Doc: improve documentation about composite-value usage.
Date
Msg-id CAKFQuwbUcXwY+wysARzvYSGq0nbiV9qKDH_XKBBNwGrQgP9O-w@mail.gmail.com
Whole thread Raw
In response to pgsql: Doc: improve documentation about composite-value usage.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Doc: improve documentation about composite-value usage.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On Tue, Nov 22, 2016 at 3:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Doc: improve documentation about composite-value usage.

Create a section specifically for the syntactic rules around whole-row
variable usage, such as expansion of "foo.*".  This was previously
documented only haphazardly, with some critical info buried in
unexpected places like xfunc-sql-composite-functions.  Per repeated
questions in different mailing lists.

​Tom,​

​I found it notable that you choose to introduce the OFFSET 0 hack instead of writing a LATERAL query in the "optimization failure" example.​

SELECT (m).* FROM (SELECT myfunc(x) AS m FROM some_table OFFSET 0) ss;

instead of​

SELECT (m).* FROM some_table, LATERAL myfunc(some_table.x) m

​​Skipping or having a different example in 9.2 seems worth it in order to introduce the now preferred way of writing such queries.

Or maybe in addition, so that some familiarity with the hack is gained should the reader encounter it in the wild.

David J.

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Doc: in back branches, don't call it a row constructor if it isn
Next
From: Robert Haas
Date:
Subject: pgsql: Remove barrier.h