functional call named notation clashes with SQLfeature
in [PgSql]
|
From: Bruce Momjian on 31 May 2010 11:22 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Tom Lane wrote: > >> So as far as I can tell, no one is opposed to replacing "expr AS name" > >> with "name := expr" in the named-parameter syntax. Obviously we had > >> better get this done before beta2. Is anyone actually working on the > >> code/docs changes? If not, I'll pick it up. > > > If we eventually are going to want to support the ANSI standard "=>" > > syntax, I am thinking we should just do it now. The larger question is > > what justification do we have of not supporting "=>". > > Not breaking hstore, as well as any third-party modules that might be > using that operator name. Did you not absorb any of the discussion > so far? Yes, but if we are going to have to honor "=>" eventually, shouldn't we just do it now? Supporting := and => seems confusing. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- 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: Bruce Momjian on 31 May 2010 11:29 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Yes, but if we are going to have to honor "=>" eventually, shouldn't we > > just do it now? Supporting := and => seems confusing. > > Personally, I haven't accepted the "if" part of that, therefore I > feel no need to argue over the "then". Right, I am asking about the "if" part. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- 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: Bruce Momjian on 31 May 2010 11:57 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. -- 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: Bruce Momjian on 31 May 2010 12:14 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. -- 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: Bruce Momjian on 31 May 2010 12:35
Andrew Dunstan wrote: > > > 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". You are right; I am seriously confused. I thought it was value => variable. I was wrong. I now see the Oracle syntax matches the Perl hash assignment syntax. The "=>" operator is helpful in documenting the correspondence between keys and values in hashes, and other paired elements in lists. %hash = ( $key => $value ); login( $username => $password ); -- 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 |