Re: UNNEST with multiple args, and TABLE with multiple funcs
От | David Fetter |
---|---|
Тема | Re: UNNEST with multiple args, and TABLE with multiple funcs |
Дата | |
Msg-id | 20130820060745.GB2099@fetter.org обсуждение исходный текст |
Ответ на | Re: UNNEST with multiple args, and TABLE with multiple funcs (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: UNNEST with multiple args, and TABLE with multiple funcs
|
Список | pgsql-hackers |
On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote: > 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 We could do this in 9.3, but all it would be is an announcement, i.e. no code change of any nature. > - and maybe use a GUC for disabling, warning and deprecating. With utmost respect, I think the general idea of setting SQL grammar via GUC is a really bad one. When we've done so in the past, it's done more harm than good, and we should not repeat it. > More, I would to see 9.4 release:). Same here! :) > x.4 are happy PostgreSQL releases :) Each one has been at least baseline happy for me since 7.1. Some have made me overjoyed, though. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: