functional call named notation clashes with SQL feature
in [PgSql]
|
From: Pavel Stehule on 31 May 2010 12:23 2010/5/31 Bruce Momjian <bruce(a)momjian.us>: > Pavel Stehule wrote: >> 2010/5/31 Bruce Momjian <bruce(a)momjian.us>: >> > Pavel Stehule wrote: >> >> >> Part of the earlier discussion was about how => was a tempting >> >> >> operator name and other users may well have chosen it precisely >> >> >> because it's so evocative. But we don't actually have any evidence of >> >> >> that. Does anyone have any experience seeing => operators in the wild? >> >> > >> >> > Tangentially, I think the SQL committee chose => because the value, then >> >> > variable, ordering is so unintuitive, and I think they wanted that >> >> > ordering because most function calls use values so they wanted the >> >> > variable at the end. >> >> >> >> maybe, maybe not. Maybe just adopt Oracle's syntax - nothing more, >> >> nothing less - like like some others. >> > >> > Yea, definitely they were copying Oracle. ?My point is that the odd >> > ordering does make sense, and the use of an arrow-like operator also >> > makes sense because of the odd ordering. >> > >> >> What I know - this feature is supported only by Oracle and MSSQL now. >> MSSQL syntax isn't available, because expected @ before variables. So >> there is available only Oracle's syntax. It is some like industrial >> standard. > > MSSQL?  Are you sure?  This is the example posted in this thread: > >     EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 > > and it more matches our := syntax than => in its argument ordering. it's not important in this discussion. Important is using some usual symbol '=' or special symbol '=>'. Our syntax is probably only one possible solution in this moment (there are minimum controversy), bud semantic isn't best. Using same operator as assign statement uses can be messy. I don't know what is a true - you have to ask of ADA designers. Regards Pavel > > -- >  Bruce Momjian  <bruce(a)momjian.us>     http://momjian.us >  EnterpriseDB               http://enterprisedb.com > >  + None of us is going to be here forever. + > > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 31 May 2010 12:26 Bruce Momjian wrote: > MSSQL? Are you sure? This is the example posted in this thread: > > EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5 > > and it more matches our := syntax than => in its argument ordering. > I think you are seriously confused, or else you are seriously confusing me. The => proposal is to have the ordering "param_name => passed_value", just as Oracle has, just as MSSQL has "@param_name = passed_value", and just as the := proposal would have "param_name := passed_value". cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 31 May 2010 15:06 Pavel Stehule <pavel.stehule(a)gmail.com> writes: > it's not important in this discussion. Important is using some usual > symbol '=' or special symbol '=>'. Our syntax is probably only one > possible solution in this moment (there are minimum controversy), bud > semantic isn't best. Using same operator as assign statement uses can > be messy. I don't know what is a true - you have to ask of ADA > designers. Well you assign a value to a named parameter, so I don't see the point. Now SELECT myfunc(a := 1, b => 2); is about fine, the only point is that the => operator looks good for associative things such as hstore, so chances that it has been used are not so low. I guess we could choose to go with := for 9.1 and revisit the => situation after the SQL standard has settled on the new version. Maybe this move would even have some impact now that we have a voice over there. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 31 May 2010 18:16 On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: > I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of => as an operator now, and definitely remove its use in hstore either now or in 9.1. +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 31 May 2010 18:23
"David E. Wheeler" <david(a)kineticode.com> writes: > On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: >> I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of => as an operator now, and definitely remove its use in hstore either now or in 9.1. My feeling is that (a) there is no hurry to do anything about an unreleased draft of the standard, and (b) perhaps Peter could lobby the committee to change the standard before it does get published. hstore's use of => is pretty well embedded already; waiting another release or two before breaking things is not going to make it significantly more painful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |