(oops this mail never reached out, it seems, resending)
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I've come round to that position too. I think allowing
parameter names to be checked only after query names is probably
the best answer.
On Thu, Apr 14, 2011 at 10:56 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2011/4/15 Jim Nasby j...@nasby.net:
On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So far the most promising proposal I've seen
Excerpts from Robert Haas's message of lun abr 18 09:33:06 -0300 2011:
I don't much like Jim's syntax suggestion (the alias really ought to
be declared within the function body, I think, not added to the CREATE
FUNCTION statement) but I don't necessarily think it's a bad idea.
What would be
On Mon, Apr 18, 2011 at 11:33 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun abr 18 09:33:06 -0300 2011:
I don't much like Jim's syntax suggestion (the alias really ought to
be declared within the function body, I think, not added to the CREATE
Robert Haas robertmh...@gmail.com writes:
rhaas=# CREATE OR REPLACE FUNCTION developer_lookup(id integer)
RETURNS text AS $$SELECT name FROM developer WHERE id = $1$$ LANGUAGE
sql STABLE;
Now, when this person attempts to recreate this function on a
hypothetical version of PostgreSQL that
On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
rhaas=# CREATE OR REPLACE FUNCTION developer_lookup(id integer)
RETURNS text AS $$SELECT name FROM developer WHERE id = $1$$ LANGUAGE
sql STABLE;
Now, when this person
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Unless we make it so that no such version ever exists. Meaning that the
code works fine as is or using WHERE id = developer_lookup.id. AS id
can't ever be the parameter
On Thu, Apr 14, 2011 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Unless we make it so that no such version ever exists. Meaning that the
code works fine as is or
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 14, 2011 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm, what I read Dimitri to be proposing is that we *require* parameter
names to be qualified with the function name. I don't recall hearing
that before. It would solve the problem
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So far the most promising proposal I've seen seems to be to let
id mean the parameter called id only when it can't refer to
anything in the query.
Yeah, I've come round to that position too. I think allowing
On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So far the most promising proposal I've seen seems to be to let
id mean the parameter called id only when it can't refer to
anything in the query.
Yeah, I've
2011/4/15 Jim Nasby j...@nasby.net:
On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So far the most promising proposal I've seen seems to be to let
id mean the parameter called id only when it can't refer to
On 04/07/2011 09:58 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstanand...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on warts such as $varname
Hello
Well, if we're going to consider 100% backwards compatibility a must,
then we should just stick with what the submitted patch does, ie,
unqualified names are matched first to query columns, and to parameters
only if there's no column match. This is also per spec if I interpreted
On 04/08/2011 10:53 AM, Pavel Stehule wrote:
For SQL language functions, I think you're right. The only caveat I have is
that if your function name is very long, having to use it as a
disambiguating qualifier can be a bit ugly.
same mechanism works well in plpgsql and nobody requested a some
On Fri, Apr 8, 2011 at 10:53 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
same mechanism works well in plpgsql and nobody requested a some
special shortcut.
I did. That mechanism sucks. But I think we're committed to doing
what the standard and/or Oracle do, so oh well.
--
Robert Haas
On Friday, April 08, 2011 04:53:27 PM Pavel Stehule wrote:
same mechanism works well in plpgsql and nobody requested a some
special shortcut.
Well, for one it sucks there as well. For another it has been introduced for
quite some time and most people have introduced naming like p_param or
On Apr 8, 2011, at 8:05 AM, Robert Haas wrote:
same mechanism works well in plpgsql and nobody requested a some
special shortcut.
I did. That mechanism sucks. But I think we're committed to doing
what the standard and/or Oracle do, so oh well.
I think I've worked around that in PL/pgSQL
On Fri, Apr 8, 2011 at 11:51 AM, David E. Wheeler da...@kineticode.com wrote:
On Apr 8, 2011, at 8:05 AM, Robert Haas wrote:
same mechanism works well in plpgsql and nobody requested a some
special shortcut.
I did. That mechanism sucks. But I think we're committed to doing
what the
On Thu, Apr 7, 2011 at 8:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Apr 7, 2011 at 8:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if we're going to consider 100% backwards compatibility a must,
then we should just stick with what the submitted patch does, ie,
unqualified names are matched first to query
But breaking people's code is not a better answer. We still
have people on 8.2 because the pain of upgrading to 8.3 is more than
they can bear, and how many releases have we spent trying to get
standard_conforming_strings worked out? I admit this probably
wouldn't be as bad, but we've
On Fri, Apr 8, 2011 at 3:56 PM, Josh Berkus j...@agliodbs.com wrote:
But breaking people's code is not a better answer. We still
have people on 8.2 because the pain of upgrading to 8.3 is more than
they can bear, and how many releases have we spent trying to get
standard_conforming_strings
Now, when this person attempts to recreate this function on a
hypothetical version of PostgreSQL that thinks id is ambiguous, it
doesn't work.
Hence the GUC. Where's the issue?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus j...@agliodbs.com wrote:
Now, when this person attempts to recreate this function on a
hypothetical version of PostgreSQL that thinks id is ambiguous, it
doesn't work.
Hence the GUC. Where's the issue?
Behavior-changing GUCs for this kind of
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus j...@agliodbs.com wrote:
Hence the GUC. Where's the issue?
Behavior-changing GUCs for this kind of thing cause a lot of problems.
If you need one GUC setting for your application to work, and the
2011/4/9 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus j...@agliodbs.com wrote:
Hence the GUC. Where's the issue?
Behavior-changing GUCs for this kind of thing cause a lot of problems.
If you need one GUC setting for
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on warts such as $varname that are
completely at odds with the style
On Apr 7, 2011, at 6:58 PM, Tom Lane wrote:
Well, if we're going to consider 100% backwards compatibility a must,
then we should just stick with what the submitted patch does, ie,
unqualified names are matched first to query columns, and to parameters
only if there's no column match. This is
On Thu, Apr 7, 2011 at 9:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on
Robert Haas wrote:
I am halfway tempted to say that we need to invent our own procedural
language that is designed not for compatibility with the SQL standard
or Oracle, but for non-crappiness.
I'm way ahead of you on that one. -- Darren Duncan
--
Sent via pgsql-hackers mailing list
On Mar 28, 2011, at 3:18 PM, Peter Eisentraut wrote:
On lör, 2011-03-26 at 09:41 -0400, Robert Haas wrote:
You can't be guaranteed that they won't standardize something
incompatible no matter what we do. We could choose to do it as you've
proposed and they could then standardize some weird
On Fri, Mar 25, 2011 at 10:05 PM, David E. Wheeler da...@kineticode.com wrote:
On Mar 25, 2011, at 9:12 PM, Robert Haas wrote:
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
idea in the first place. If
On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
+1 on using $foo. Even with the standardization risk I think it's the
best choice. Prefer $foo to ${foo} though.
What standardization risk? The standard has already existed for 10
years and is widely implemented.
--
Sent via
On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
+1 on using $foo. Even with the standardization risk I think it's the
best choice. Prefer $foo to ${foo} though.
What standardization risk? The standard has
Merlin Moncure wrote:
On Fri, Mar 25, 2011 at 10:05 PM, David E. Wheeler da...@kineticode.com wrote:
On Mar 25, 2011, at 9:12 PM, Robert Haas wrote:
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
idea in
On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
+1 on using $foo. Even with the standardization risk I think it's the
best choice. Prefer $foo to ${foo}
On Tue, Apr 5, 2011 at 2:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
+1 on using $foo. Even with the
2011/4/5 Peter Eisentraut pete...@gmx.net:
On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
+1 on using $foo. Even with the standardization risk I think it's
2011/4/5 Merlin Moncure mmonc...@gmail.com:
On Tue, Apr 5, 2011 at 2:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure
On tis, 2011-04-05 at 14:45 -0500, Merlin Moncure wrote:
Talking about the standards compliance of functions is a bit silly:
our implementation of functions isn't even close to approximating what
looks to be the standard
That doesn't mean it couldn't be better in the future. We shouldn't
take
On Tue, Apr 5, 2011 at 3:47 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-04-05 at 14:45 -0500, Merlin Moncure wrote:
Talking about the standards compliance of functions is a bit silly:
our implementation of functions isn't even close to approximating what
looks to be the standard
On 04/05/2011 03:45 PM, Merlin Moncure wrote:
Talking about the standards compliance of functions is a bit silly:
our implementation of functions isn't even close to approximating what
looks to be the standard (according to this at least:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on warts such as $varname that are
completely at odds with the style of the rest of the language. That doesn't
On lör, 2011-03-26 at 09:41 -0400, Robert Haas wrote:
You can't be guaranteed that they won't standardize something
incompatible no matter what we do. We could choose to do it as you've
proposed and they could then standardize some weird syntax - the = is
a fairly relevant example of exactly
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 26, 2011 at 5:19 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I think the best choice is to only accept qualified parameter names in
SQL functions (function_name.parameter_name). If a referenced table
share the function's name,
On Mar 27, 2011, at 6:11 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
That syntax is sufficiently unwieldly that few people will want to use
it in real life, but certainly the backward compatibility problem is
much less than with what Tom
On Fri, Mar 25, 2011 at 09:12:33PM -0400, Robert Haas wrote:
On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mar 25, 2011, at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, maybe, but it's not like it's subtle or hard to
On 03/27/2011 09:42 AM, David Fetter wrote:
On Fri, Mar 25, 2011 at 09:12:33PM -0400, Robert Haas wrote:
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
idea in the first place. If we used $foo or ?foo
2011/3/27 Andrew Dunstan and...@dunslane.net:
On 03/27/2011 09:42 AM, David Fetter wrote:
On Fri, Mar 25, 2011 at 09:12:33PM -0400, Robert Haas wrote:
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
On Sun, Mar 27, 2011 at 06:52:03PM +0200, Pavel Stehule wrote:
Syntax for named parameters should be consistent with prepared
statement. Is there any comments in standard?
Well, there's section 4.24 which says:
In SQL-statements that are executed dynamically, the parameters are
called dynamic
2011/3/27 Martijn van Oosterhout klep...@svana.org:
On Sun, Mar 27, 2011 at 06:52:03PM +0200, Pavel Stehule wrote:
Syntax for named parameters should be consistent with prepared
statement. Is there any comments in standard?
Well, there's section 4.24 which says:
In SQL-statements that are
On Mar 25, 2011, at 11:23 PM, Tom Lane wrote:
If this were PL/perl, or PL/almost-anything-except-SQL, I could get
behind such a proposal. But it's not, it's SQL; and SQL doesn't do
things that way. SQL's idea of disambiguation is qualified names.
And even more to the point: to the extent
On Mar 25, 2011, at 11:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If this were PL/perl, or PL/almost-anything-except-SQL, I could get
behind such a proposal. But it's not, it's SQL; and SQL doesn't do
things that way. SQL's idea of disambiguation is qualified names.
And even more to the
Joshua Berkus j...@agliodbs.com writes:
Personally I'd vote for *not* having any such dangerous semantics as
that. We should have learned better by now from plpgsql experience.
I think the best idea is to throw error for ambiguous references,
period.
As a likely heavy user of this feature,
2011/3/26 Dimitri Fontaine dimi...@2ndquadrant.fr:
Joshua Berkus j...@agliodbs.com writes:
Personally I'd vote for *not* having any such dangerous semantics as
that. We should have learned better by now from plpgsql experience.
I think the best idea is to throw error for ambiguous references,
On Sat, Mar 26, 2011 at 5:19 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I think the best choice is to only accept qualified parameter names in
SQL functions (function_name.parameter_name). If a referenced table
share the function's name, ERROR out and HINT to alias the table name.
If
Attached is a WIP patch that allows SQL-language functions to reference
their parameters by name.
It uses p_post_columnref_hook, so potentially ambiguous references
prefer the column... that seems to make the most sense, both because it
avoids a backwards incompatibility, and it conforms with
Matthew Draper matt...@trebex.net writes:
Attached is a WIP patch that allows SQL-language functions to reference
their parameters by name.
It uses p_post_columnref_hook, so potentially ambiguous references
prefer the column... that seems to make the most sense, both because it
avoids a
2011/3/25 Tom Lane t...@sss.pgh.pa.us:
Matthew Draper matt...@trebex.net writes:
Attached is a WIP patch that allows SQL-language functions to reference
their parameters by name.
It uses p_post_columnref_hook, so potentially ambiguous references
prefer the column... that seems to make the
Pavel Stehule pavel.steh...@gmail.com writes:
2011/3/25 Tom Lane t...@sss.pgh.pa.us:
I think the best idea is to throw error for ambiguous references,
period.
There can be GUC for controlling use or don't use a parameter names. I
am for GUC, because there will be a bilion conflicts. But a
2011/3/25 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/3/25 Tom Lane t...@sss.pgh.pa.us:
I think the best idea is to throw error for ambiguous references,
period.
There can be GUC for controlling use or don't use a parameter names. I
am for GUC, because
On Mar 25, 2011, at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
GUCs are not tremendously helpful for problems such as this. If we
actually wanted to preserve full backwards compatibility, we'd need to
think of a way to mark SQL functions per-function as to what to do.
But I don't think
Robert Haas robertmh...@gmail.com writes:
On Mar 25, 2011, at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But I don't think that's necessary. Up to now there's been relatively
little use for naming the parameters of SQL functions, so I think there
will be few conflicts in the field if we just
On Mar 25, 2011, at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, maybe, but it's not like it's subtle or hard to fix.
Depends how much of it you have. I've become very skeptical of anything that
breaks pg_dump-and-reload-ability. And doubly so now that such problems also
mean breaking
Robert Haas robertmh...@gmail.com writes:
On Mar 25, 2011, at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, maybe, but it's not like it's subtle or hard to fix.
Depends how much of it you have. I've become very skeptical of
anything that breaks pg_dump-and-reload-ability.
This wouldn't
On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mar 25, 2011, at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, maybe, but it's not like it's subtle or hard to fix.
Depends how much of it you have. I've become very skeptical
Tom,
Personally I'd vote for *not* having any such dangerous semantics as
that. We should have learned better by now from plpgsql experience.
I think the best idea is to throw error for ambiguous references,
period.
As a likely heavy user of this feature, I agree with Tom here. I really
On Mar 25, 2011, at 9:22 PM, Joshua Berkus j...@agliodbs.com wrote:
Tom,
Personally I'd vote for *not* having any such dangerous semantics as
that. We should have learned better by now from plpgsql experience.
I think the best idea is to throw error for ambiguous references,
period.
As
Robert Haas robertmh...@gmail.com writes:
On Mar 25, 2011, at 9:22 PM, Joshua Berkus j...@agliodbs.com wrote:
Also, I don't understand why this would be a dump/reload issue if $1 and $2
continue to work.
Because an identifier that previously referred unambiguously to a column
might now be
On Mar 25, 2011, at 9:12 PM, Robert Haas wrote:
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
idea in the first place. If we used $foo or ?foo or ${foo} or $.foo
or foo!!$#? to mean the parameter
Robert Haas robertmh...@gmail.com writes:
As I've said before, I believe that the root cause of this problem is
that using the same syntax for variables and column names is a bad
idea in the first place. If we used $foo or ?foo or ${foo} or $.foo
or foo!!$#? to mean the parameter called foo,
72 matches
Mail list logo
