Re: named parameters in SQL functions

On Nov 15, 2009, at 11:35 AM, Greg Stark wrote:

> 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.

I don't know of anyone suggesting such a thing.

> 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.

So what is the $ for in $1, $2, etc.?

> 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.

It's not in SQL; it's in SQL functions (and DO blocks). AFAIK, the major database vendors all use some sort of
characterto identify variables within functions. It's proven, avoids conflicts (you can't have an identifier named
$foo,as Andrew just pointed out), and just generally makes maintenance easier. 

Best,

David