Re: proposal sql: labeled function params
От | daveg |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 20080823224835.GS28154@sonic.net обсуждение исходный текст |
Ответ на | Re: proposal sql: labeled function params (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: proposal sql: labeled function params
|
Список | pgsql-hackers |
On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote: > "Pavel Stehule" <pavel.stehule@gmail.com> writes: > > > Hello > > > > 2008/8/23 Peter Eisentraut <peter_e@gmx.net>: > >> On Friday 22 August 2008 07:41:30 Decibel! wrote: > >>> If we're really worried about it we can have a GUC for a few versions > >>> that turns off named parameter assignment. But I don't think we > >>> should compromise the design on the theory that some folks might be > >>> using that as an operator *and* can't change their application to > >>> wrap it's use in (). > >> > >> Even if that were a reasonable strategy, you can't use GUC parameters to alter > >> parser behavior. > > > > I thing, so it's possible - in this case. We should transform named > > params to expr after syntax analyze. > > So for a bit of useless syntactic sugar we should introduce conflicts with > named parameters, conflicts with operators, introduce an un-sqlish syntax and > remove a feature users have already made use of and introduce backwards > compatibility issues for those users? > > At any point in this discussion has anyone explained why these labels would > actually be a good idea? I was missing that too. What is this for that makes it so compelling? -dg -- David Gould daveg@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects.
В списке pgsql-hackers по дате отправления: