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, we
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)
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
2009/11/15 Andrew Dunstan and...@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
2009/11/15 Andrew Chernow a...@esilo.com:
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,
On Sun, Nov 15, 2009 at 12:37 PM, Andrew Dunstan and...@dunslane.net 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.
On Sun, Nov 15, 2009 at 5:49 PM, Andrew Chernow a...@esilo.com 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
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.
2009/11/15 David E. Wheeler da...@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
On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule pavel.steh...@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
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler da...@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
2009/11/16 Andrew Dunstan and...@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
2009/11/15 Greg Stark gsst...@mit.edu:
On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule pavel.steh...@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
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 a
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
2009/11/15 Andrew Chernow a...@esilo.com:
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$)
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler da...@kineticode.com 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
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
On Sun, Nov 15, 2009 at 7:25 PM, David E. Wheeler da...@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
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
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 Sun, Nov 15, 2009 at 7:56 PM, Andrew Chernow a...@esilo.com 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
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 error
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.
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan and...@dunslane.net 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.
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan and...@dunslane.net 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 a...@esilo.com 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
Tom Lane wrote:
Andrew Chernow a...@esilo.com 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
Andrew Chernow a...@esilo.com 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
On Sun, Nov 15, 2009 at 8:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, if the funcname.varname gadget will work, as you suggest elsewhere it
could, I think that would
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
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com 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
Robert Haas wrote:
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan and...@dunslane.net 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
On Sun, Nov 15, 2009 at 10:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan and...@dunslane.net
wrote:
Robert Haas wrote:
(But having said that, an alternate qualification name is something
that could be implemented if there
2009/11/16 Andrew Dunstan and...@dunslane.net:
Robert Haas wrote:
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan and...@dunslane.net
wrote:
Robert Haas wrote:
(But having said that, an alternate qualification name is something
that could be implemented if there were any agreement on
2009/11/16 Robert Haas robertmh...@gmail.com:
On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan and...@dunslane.net
wrote:
Robert Haas wrote:
(But having said that, an alternate qualification name is
42 matches
Mail list logo
