From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PL/pgSQL proposal: using list of scalars in assign |
Date: | 2005-12-22 23:53:28 |
Message-ID: | 43AB3C78.6070206@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>David Fetter <david(at)fetter(dot)org> writes:
>
>
>>How about:
>><target2> := {row|record|variable|'[ROW](' comma separated list of scalar vars ')'}
>>instead, where the ROW is optional?
>>
>>
>
>If we're going to do this at all (which I'm still agin), I think the ROW
>keyword is important to minimize ambiguity. If you are allowed to start
>a statement with just "(x, ..." then there will be way too many
>situations where the parser gets confused by slightly bad input,
>resulting in way-off-base syntax error reports. Or worse, no syntax
>error, but a function that does something else than you expected.
>
>I know that ROW is optional in the bit of SQL syntax that this proposal
>is based on, but that's only because the SQL spec says we have to, not
>because it's a good idea.
>
>
>
>
I see no virtue in this either. It strikes me as just more syntactic
sugar, and unless I am misreading or out of date it would be another
incompatibility with Oracle. I don't mind doing that, but I think it
should be for a better reason than that it accords with someone's taste
in syntactic style. I'd be somewhat more persuaded if Oracle did this. I
also agree with Tom's comments about requiring ROW. As I observed
regarding another syntax proposal, terseness is not always good, and
redundancy is not always bad.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-12-22 23:57:19 | Re: Disparity in search_path SHOW and SET |
Previous Message | Tom Lane | 2005-12-22 23:53:12 | Re: [pgadmin-hackers] Client-side password encryption |