Re: Review: UNNEST (and other functions) WITH ORDINALITY

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Stephen Frost <sfrost(at)snowman(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY
Date: 2013-07-24 01:16:38
Message-ID: e00f67da5151752359d805038fcc35db@news-out.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost said:
> [stuff about foreign tables]

I think the issue with foreign tables is probably moot because if you
_did_ want to have some types of foreign tables with a fixed
ordinality, you'd probably also want qual pushdown to work for it
(i.e. so that WHERE rownum=123 doesn't have to filter all the rows),
whereas with SRFs this doesn't really apply.

For this to work, foreign tables with a fixed ordering would have to
provide that in the FDW - which is in any case the only place that
knows whether a fixed order would even make any sense.

So I see no overlap here with the SRF ordinality case.

As for VALUES, the spec regards those as constructing a table and
therefore not having any inherent order - the user can add their own
ordinal column if need be. Even if you did want to add WITH ORDINALITY
for VALUES, though, it would actually make more sense to do it in the
Values Scan node since that maintains its own ordinal position already.

--
Andrew (irc:RhodiumToad)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Quan Zongliang 2013-07-24 01:19:25 Re: improve Chinese locale performance
Previous Message Stephen Frost 2013-07-24 00:35:27 Re: Review: UNNEST (and other functions) WITH ORDINALITY