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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-committers(at)postgresql(dot)org" <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Doc: improve documentation about composite-value usage.
Date: 2016-11-23 03:04:37
Message-ID: 25895.1479870277@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> ​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

Meh ... I'm not really sure that the latter is any less of a hack for this
purpose, or that we'd never optimize it into the unwanted form. LATERAL
is a good way to fix the weird semantics of set-returning functions in the
tlist, but this is not that case.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-11-23 18:46:18 pgsql: Make sure ALTER TABLE preserves index tablespaces.
Previous Message Robert Haas 2016-11-23 01:28:38 pgsql: Remove barrier.h

Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2016-11-23 03:11:28 Alternative MATERIALIZED VIEW design and implementation with history table and other features
Previous Message Robert Haas 2016-11-23 03:01:03 UNDO and in-place update