Re: named parameters in SQL functions - Mailing list pgsql-hackers

From Greg Stark
Subject Re: named parameters in SQL functions
Date
Msg-id 407d949e0911151135j1d782192j8192772346e38a81@mail.gmail.com
Whole thread Raw
In response to Re: named parameters in SQL functions  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: named parameters in SQL functions
List pgsql-hackers
On Sun, Nov 15, 2009 at 7:25 PM, David E. Wheeler <david@kineticode.com> wrote:
> On Nov 15, 2009, at 11:21 AM, Greg Stark wrote:
>
>
> $foo should be killed off as a valid identifier, IMNSHO.
>
> But failing that, some other sigil would be most welcome.

I don't think SQL is the height of language design either. But trying
to turn it into another language piece by piece is not gong to make it
any nicer.

A sigil here doesn't accomplish anything. The identifiers in question
are *just* like other identifiers. They can be used in expressions
just like other columns, they have various types, they have the same
syntax as other columns, the sigil doesn't mean anything.

I think what may be making this tempting is that they look vaguely
like ODBC/JDBC/DBI placeholders like :foo. However they're very very
different. In those cases the sigil is marking the sigil outside the
SQL syntax. They will be replaced textually without parsing the SQL at
all. It's actually very confusing having $foo indicate something
within SQL since it makes it look like it's some external thing from
another layer like the placeholders.

-- 
greg


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER ROLE/DATABASE RESET ALL versus security
Next
From: Heikki Linnakangas
Date:
Subject: Re: Hot standby, race condition between recovery snapshot and commit