| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LATERAL, UNNEST and spec compliance |
| Date: | 2013-01-25 18:54:33 |
| Message-ID: | 20130125185433.GV16126@tamriel.snowman.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> However ... David is wrong to claim that it's zero-risk. It's true that
> an SRF can't contain any side-references today, but it can contain an
> outer reference. Consider a case like
>
> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...)
I see what you mean, but on the other hand, that looks like something we
might actually want to complain about as 'y' is pretty clearly ambiguous
here. I'm a bit surprised that doesn't already throw an error.
> This is a little bit far-fetched, but it could happen. As against that,
> we make incompatible changes in every release, and it does seem like
> assuming LATERAL for functions in FROM would be a usability gain most
> of the time. And special-casing UNNEST to satisfy the standard seems
> *really* ugly.
It's definitely far-fetched, imv. If it's possible, within reason, to
explicitly throw a "please disambiguate 'y'" type of error in those
specific cases, that'd be nice, but I don't think it'd be required. A
mention in the release notes would be sufficient.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2013-01-25 18:59:41 | Re: Doc patch, normalize search_path in index |
| Previous Message | Peter Eisentraut | 2013-01-25 18:54:06 | Re: "pg_ctl promote" exit status |