| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: UNNEST with multiple args, and TABLE with multiple funcs |
| Date: | 2013-08-19 17:45:23 |
| Message-ID: | CAFj8pRCFDW0QKQS4coTgpWXX2KLX82dLGpGJ9LD53hP2nhEbbQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello
Harder maybe but it may still be cleaner in the long run.
>
> Overall, it's my intention here to remove as many as feasible of the old
>> reasons why one might use an SRF in the select list.
>>
>
> Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having
> WITH ORDINALITY and this feature, I would vote for removing
> SRF-in-targetlist and call the release PostgreSQL 10.0.
>
Although I would to remove SRF from targetlist, I don't think so this hurry
strategy is good idea. We should to provide new functionality and old
functionality one year as minimum, and we should to announce so this
feature is deprecated - and maybe use a GUC for disabling, warning and
deprecating. More, I would to see 9.4 release:). x.4 are happy PostgreSQL
releases :)
Regards
Pavel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2013-08-19 17:50:38 | Re: danger of stats_temp_directory = /dev/shm |
| Previous Message | Bruce Momjian | 2013-08-19 17:42:21 | Re: Should we remove "not fast" promotion at all? |