(oops this mail never reached out, it seems, resending)
"Kevin Grittner" writes:
> Tom Lane 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.
>
> That seems the most useful and least
On Mon, Apr 18, 2011 at 11:33 AM, Alvaro Herrera
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
>> FUNCTION statement
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 b
On Thu, Apr 14, 2011 at 10:56 PM, Pavel Stehule wrote:
> 2011/4/15 Jim Nasby :
>> On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
>>> Tom Lane wrote:
Robert Haas writes:
>>>
> So far the most promising proposal I've seen seems to be to let
> id mean the parameter called id only w
2011/4/15 Jim Nasby :
> On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
>> Tom Lane wrote:
>>> Robert Haas 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
On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
> Tom Lane wrote:
>> Robert Haas 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 positio
Tom Lane wrote:
> Robert Haas 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
> parameter names to be checked onl
Robert Haas writes:
> On Thu, Apr 14, 2011 at 1:55 PM, Tom Lane 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 perhaps, but I think the moans
>>
On Thu, Apr 14, 2011 at 1:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
>> 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
Robert Haas writes:
> On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
> 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 in this case, you're just fine.
>>
On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine
wrote:
> Robert Haas 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
Robert Haas 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 thinks "id" is amb
2011/4/9 Tom Lane :
> Robert Haas writes:
>> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus 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
>> extension yo
Robert Haas writes:
> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus 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
> extension you have installed needs the o
On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus 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 thing cause
> 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 (pgsql-
On Fri, Apr 8, 2011 at 3:56 PM, Josh Berkus 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 worked out?
> 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
Merlin Moncure writes:
> On Thu, Apr 7, 2011 at 8: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
>> on
On Thu, Apr 7, 2011 at 8:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan 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
On Fri, Apr 8, 2011 at 11:51 AM, David E. Wheeler 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 standard and/
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/
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 v_pa
On Fri, Apr 8, 2011 at 10:53 AM, Pavel Stehule 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
EnterpriseDB: http://ww
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
s
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 interp
On 04/07/2011 09:58 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan 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
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 (pgsql-hac
On Thu, Apr 7, 2011 at 9:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan 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
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. Th
Robert Haas writes:
> On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan 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
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan 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
> do anything exce
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:
http://farrago.sourceforge.net/design/UserDefinedTypesAn
On Tue, Apr 5, 2011 at 3:47 PM, Peter Eisentraut 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
>
> That d
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
ta
2011/4/5 Merlin Moncure :
> On Tue, Apr 5, 2011 at 2:33 PM, Peter Eisentraut wrote:
>> On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
>>> On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut wrote:
>>> > On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
>>> >> +1 on using $foo. Even wi
2011/4/5 Peter Eisentraut :
> On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
>> On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut 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 choic
On Tue, Apr 5, 2011 at 2:33 PM, Peter Eisentraut wrote:
> On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
>> On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut wrote:
>> > On tis, 2011-04-05 at 11:21 -0500, Merlin Moncure wrote:
>> >> +1 on using $foo. Even with the standardization risk I th
On tis, 2011-04-05 at 15:05 -0400, Robert Haas wrote:
> On Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut 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.
Merlin Moncure wrote:
On Fri, Mar 25, 2011 at 10:05 PM, David E. Wheeler 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 Tue, Apr 5, 2011 at 1:45 PM, Peter Eisentraut 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 already exis
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 pgs
On Fri, Mar 25, 2011 at 10:05 PM, David E. Wheeler 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 we used $f
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 we
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 exac
2011/3/27 Martijn van Oosterhout :
> 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
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 dynami
2011/3/27 Andrew Dunstan :
>
>
> 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
>>> id
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 or
On Fri, Mar 25, 2011 at 09:12:33PM -0400, Robert Haas wrote:
> On Fri, Mar 25, 2011 at 8:58 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mar 25, 2011, at 7:45 PM, Tom Lane wrote:
> >>> Well, maybe, but it's not like it's subtle or hard to fix.
> >
> >> Depends how much of it you have. I'v
On Mar 27, 2011, at 6:11 AM, Dimitri Fontaine wrote:
> Robert Haas 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 proposed.
>
> Well, we would still support
Robert Haas writes:
> On Sat, Mar 26, 2011 at 5:19 PM, Dimitri Fontaine
> 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 n
On Sat, Mar 26, 2011 at 5:19 PM, Dimitri Fontaine
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 we allow more tha
2011/3/26 Dimitri Fontaine :
> Joshua Berkus 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
Joshua Berkus 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, I agree
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 ext
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 ext
Robert Haas 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", then this woul
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 parame
Robert Haas writes:
> On Mar 25, 2011, at 9:22 PM, Joshua Berkus 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 ambiguous, if there is a paramet
On Mar 25, 2011, at 9:22 PM, Joshua Berkus 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 a like
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 Fri, Mar 25, 2011 at 8:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mar 25, 2011, at 7:45 PM, Tom Lane 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-abi
Robert Haas writes:
> On Mar 25, 2011, at 7:45 PM, Tom Lane 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 break pg_dump scripts, because they
On Mar 25, 2011, at 7:45 PM, Tom Lane 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 pg_upgrade after the
Robert Haas writes:
> On Mar 25, 2011, at 4:20 PM, Tom Lane 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 change the behavior.
> Oh wow,
On Mar 25, 2011, at 4:20 PM, Tom Lane 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 that's necessary. U
2011/3/25 Tom Lane :
> Pavel Stehule writes:
>> 2011/3/25 Tom Lane :
>>> 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 talk abo
Pavel Stehule writes:
> 2011/3/25 Tom Lane :
>> 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 talk about
> priorities - sql identif
2011/3/25 Tom Lane :
> Matthew Draper 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
>
Matthew Draper 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 backwards incompat
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 SQL
72 matches
Mail list logo
