From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Andrew Chernow <ac(at)esilo(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: named parameters in SQL functions |
Date: | 2009-11-15 18:59:40 |
Message-ID: | FB26797F-AFD5-40BF-868F-ABB13978387C@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Nov 15, 2009, at 10:54 AM, Greg Stark wrote:
> I'm japh too -- but that doesn't mean grabbing one little aesthetic
> from Perl without copying the whole concept behind it makes any sense.
> Perl sigils are an important part of the language and are a basic part
> of the syntax. They aren't just a "this is a variable" marker.
> Dropping one use of them into a language that doesn't use them
> anywhere else just makes the language into a mishmash.
Well, no, just because we're talking about adopting $var doesn't mean we're trying to turn SQL or PL/pgSQL into Perl. It means that we want to signify that a token is a variable, as opposed to something else (hence “sigil”). That doesn't make it a mishmash unless you think you suddenly have Perl (or shell) semantics, which would be a pretty weird expectation.
> I don't see any purpose to using such markers anyways. We have a
> parser, we have a symbol table, we should use them; these identifiers
> are just like other identifiers.
See the discussion of conflicts with column names in the recent thread. A sigil would eliminate that problem -- and we already have $1 and friends, so this is just an extension of that in my view.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2009-11-15 19:13:56 | Re: named parameters in SQL functions |
Previous Message | Pavel Stehule | 2009-11-15 18:59:39 | Re: named parameters in SQL functions |