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 character to 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