Re: named parameters in SQL functions

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

In response to

Browse pgsql-hackers by date

  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