Re: functional call named notation clashes with SQL feature - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id 201005311635.o4VGZW112075@momjian.us
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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
otherpaired elements in lists.
 
              %hash = ( $key => $value );              login( $username => $password );

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + None of us is going to be here forever. +



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: functional call named notation clashes with SQL feature
Next
From: Bruce Momjian
Date:
Subject: Re: Adding xpath_exists function