On sön, 2009-11-15 at 12:37 -0500, Andrew Dunstan wrote:
> 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,
2009/11/16 Robert Haas :
> On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan wrote:
>> Robert Haas wrote:
>>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan
>>> wrote:
Robert Haas wrote:
>> (But having said that, an alternate qualification name is something
>> that could be implement
2009/11/16 Andrew Dunstan :
>
>
> Robert Haas wrote:
>>
>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan
>> wrote:
>>
>>>
>>> Robert Haas wrote:
>>>
>
> (But having said that, an alternate qualification name is something
> that could be implemented if there were any agreement on what
On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan
>> wrote:
>>> Robert Haas wrote:
> (But having said that, an alternate qualification name is something
> that could be implemented if there were any agreement on
On Sun, Nov 15, 2009 at 10:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> I don't see why it would need to be a reserved word. We're not
>> changing how it gets parsed, just what it means. At any rate
>> "FUNCTION." is a 9-character prefix, which is rather longer than I
>> would prefer.
>
> Th
Robert Haas wrote:
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan wrote:
Robert Haas wrote:
(But having said that, an alternate qualification name is something
that could be implemented if there were any agreement on what to use.)
Well that is the tricky part, for sure.
Robert Haas writes:
> I don't see why it would need to be a reserved word. We're not
> changing how it gets parsed, just what it means. At any rate
> "FUNCTION." is a 9-character prefix, which is rather longer than I
> would prefer.
This from the guy who likes 40-character function names?
Andrew Dunstan writes:
> Robert Haas wrote:
>> Well that is the tricky part, for sure. I would personally prefer
>> something like ${name} rather than a prefix, but I think you're likely
>> to veto that outright. So, anything reasonably short would be an
>> improvement over the status quo. self
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>>
>>> (But having said that, an alternate qualification name is something
>>> that could be implemented if there were any agreement on what to use.)
>>>
>>
>> Well that is the tricky part, for sure. I would personally p
Robert Haas wrote:
(But having said that, an alternate qualification name is something
that could be implemented if there were any agreement on what to use.)
Well that is the tricky part, for sure. I would personally prefer
something like ${name} rather than a prefix, but I think you're
On Sun, Nov 15, 2009 at 8:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote:
>>> Well, if the funcname.varname gadget will work, as you suggest elsewhere it
>>> could, I think that would suffice. I had assumed that was just something in
>>> the
Andrew Chernow writes:
> Tom Lane wrote:
>> It's certainly true that the function name itself is not immune from
>> conflicts of that sort ... in fact I think we saw a bug report recently
>> from someone who had intentionally chosen a plpgsql function name equal
>> to a table name used in the func
Tom Lane wrote:
Andrew Chernow writes:
Tom Lane wrote:
(But having said that, an alternate qualification name is something
that could be implemented if there were any agreement on what to use.)
Would something like ARG.name be acceptable?
It all depends on how likely you think it is that
Andrew Chernow writes:
> Tom Lane wrote:
>> (But having said that, an alternate qualification name is something
>> that could be implemented if there were any agreement on what to use.)
> Would something like ARG.name be acceptable?
It all depends on how likely you think it is that the function
Tom Lane wrote:
Robert Haas writes:
On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote:
Well, if the funcname.varname gadget will work, as you suggest elsewhere it
could, I think that would suffice. I had assumed that was just something in
the plpgsql engine.
That gadget isn't horribly
Robert Haas writes:
> On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote:
>> Well, if the funcname.varname gadget will work, as you suggest elsewhere it
>> could, I think that would suffice. I had assumed that was just something in
>> the plpgsql engine.
> That gadget isn't horribly convenien
On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> 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
Tom Lane wrote:
Andrew Dunstan writes:
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.
Throw error if ambiguous. We
Andrew Dunstan writes:
> 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.
Throw error if ambiguous. We already resolved this
On Nov 15, 2009, at 12:09 PM, Greg Stark wrote:
> 1) Error messages which mention column names are supposed to quote the
> column name to set it apart from the error string. This also
> guarantees that weird column names are referenced correctly as "foo
> bar" or "$foo" so the reference in the err
On Sun, Nov 15, 2009 at 7:56 PM, Andrew Chernow wrote:
>> The point is that $ is a perfectly valid SQL identifier character and
>> $foo is a perfectly valid identifier. You can always quote any
>> identifier (yes, after case smashing) so you would expect if $foo is a
>> valid identifier then "$foo
The point is that $ is a perfectly valid SQL identifier character and
$foo is a perfectly valid identifier. You can always quote any
identifier (yes, after case smashing) so you would expect if $foo is a
valid identifier then "$foo" would refer to the same identifier.
This case already exists
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
David E. Wheeler wrote:
$foo should be killed off as a valid identifier, IMNSHO.
It's only legal when quoted. Unquoted indetifiers can't begin with $.
see scan.l:
ident_start [A-Za-z\200-\377_]
ident_cont [A-Za-z\200-\377_0-9\$]
identifier
On Sun, Nov 15, 2009 at 7:25 PM, David E. Wheeler 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 tr
On Nov 15, 2009, at 11:21 AM, Greg Stark wrote:
> No, that's not the same.
>
> The point is that $ is a perfectly valid SQL identifier character and
> $foo is a perfectly valid identifier. You can always quote any
> identifier (yes, after case smashing) so you would expect if $foo is a
> valid id
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler wrote:
>> 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
2009/11/15 Andrew Chernow :
>
>>> 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.
>>
>> no, it should be safe (if you don't use for dollar quoting some like
>> $variablena
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.
no, it should be safe (if you don't use for dollar quoting some like
$variablename$)
Actually, I was thinking of something like
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
2009/11/15 Greg Stark :
> On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule
> 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
2009/11/16 Andrew Dunstan :
> 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
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler 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 be
On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule 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
2009/11/15 David E. Wheeler :
> 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 w
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-sq
On Sun, Nov 15, 2009 at 5:49 PM, Andrew Chernow wrote:
> Andrew Dunstan wrote:
>>
>> 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 n
On Sun, Nov 15, 2009 at 12:37 PM, Andrew Dunstan wrote:
> 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
2009/11/15 Andrew Chernow :
> Andrew Dunstan wrote:
>>
>> 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, w
2009/11/15 Andrew Dunstan :
>
> 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 mark
Andrew Dunstan wrote:
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
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) o
42 matches
Mail list logo
