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
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 |
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 |