From: "David E. Wheeler" on
On Nov 15, 2009, at 10:19 AM, Greg Stark wrote:

>> I like the special marker idea. A '$' would be nice because its already in
>> use for similar purposes, but I think that would lead to ambiguity with
>> dollar quoting.
>
> I think that would be a big break with everything else and very
> non-sql-ish. We don't use these in plpgsql and we don't use them
> anywhere else in sql.

*ahem* $1 *ahem*

> Moreover you would still have conflicts possible because sql can quote
> identifiers so people can have columns named "$foo". You would have a
> weird syntactic detail where "$foo" would mean something different
> than $foo even though they're both valid identifiers.

Same with Foo and "Foo", no?

> I'm not sure it wouldn't conflict with some drivers either. DBI uses
> :foo and ? but I have a vague recollection some drivers did use $foo.

I don't think that would come up, because the $vars are in the body of the function, not in a typical driver call.

Personally, I like $var, but @var would be okay, and @@var is acceptable. But I'm JAPH, so my biases should be obvious.

Best,

David
--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on
2009/11/15 David E. Wheeler <david(a)kineticode.com>:
> On Nov 15, 2009, at 10:19 AM, Greg Stark wrote:
>
>>> I like the special marker idea.  A '$' would be nice because its already in
>>> use for similar purposes, but I think that would lead to ambiguity with
>>> dollar quoting.
>>
>> I think that would be a big break with everything else and very
>> non-sql-ish. We don't use these in plpgsql and we don't use them
>> anywhere else in sql.
>
> *ahem* $1 *ahem*
>
>> Moreover you would still have conflicts possible because sql can quote
>> identifiers so people can have columns named "$foo". You would have a
>> weird syntactic detail where "$foo" would mean something different
>> than $foo even though they're both valid identifiers.
>
> Same with Foo and "Foo", no?
>
>> I'm not sure it wouldn't conflict with some drivers either. DBI uses
>> :foo and ? but I have a vague recollection some drivers did use $foo.
>
> I don't think that would come up, because the $vars are in the body of the function, not in a typical driver call.
>
> Personally, I like $var, but @var would be okay, and @@var is acceptable. But I'm JAPH, so my biases should be obvious.

@var or @@var should be a break for people from MySQL. @var are r/w in
MySQL and @@var are global in T-SQL. So people could be confused.

Regards
Pavel

>
> Best,
>
> David
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Greg Stark on
On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote:
>> Personally, I like $var, but @var would be okay, and @@var is acceptable. But I'm JAPH, so my biases should be obvious.
>
> @var or @@var should be a break for people from MySQL. @var are r/w in
> MySQL and @@var are global in T-SQL. So people could be confused.

Besides, do we think MySQL and T-SQL are the heights of good language design?


--
greg

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Greg Stark on
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler <david(a)kineticode.com> wrote:
> Personally, I like $var, but @var would be okay, and @@var is acceptable. But I'm JAPH, so my biases should be obvious.


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.

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.



--
greg

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Brendan Jurd on
2009/11/16 Andrew Dunstan <andrew(a)dunslane.net>:
> At Tom's suggestion I am looking at allowing use of parameter names in SQL
> functions instead of requiring use of $1 etc. That raises the question of
> how we would disambiguate a parameter name from a column name. Essentially,
> ISTM, we could use some special marker such as @ (c.f. SQL Server) or :
> (c.f. ecpg) or else we could have some rule that says which name takes
> precedence. I think I prefer a special marker, other things being equal. Is
> there a standard on this?

Sorry if I'm missing something important here, but why not just
resolve the parameter names in whatever way PL/PgSQL has been doing
it? It seems to work well.

FWIW I always prefix my parameter names with _ to differentiate them
from columns.

Cheers,
BJ

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers