Re: proposal sql: labeled function params
От | Gregory Stark |
---|---|
Тема | Re: proposal sql: labeled function params |
Дата | |
Msg-id | 87myj3pvd2.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: proposal sql: labeled function params ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal sql: labeled function params
Re: proposal sql: labeled function params |
Список | pgsql-hackers |
"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? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
В списке pgsql-hackers по дате отправления: