2009/5/21 Steve Prentice :
> On May 20, 2009, at 10:24 AM, Pavel Stehule wrote:
>>
>> this problem is little bit deeper and is related to plpgsql method for
>> SQL query processing.
>>
>> I thing so there are two solutions:
>>
>> a) use dynamic SQL
>> b) use double quotes for identifier - identifie
On May 20, 2009, at 10:24 AM, Pavel Stehule wrote:
this problem is little bit deeper and is related to plpgsql method for
SQL query processing.
I thing so there are two solutions:
a) use dynamic SQL
b) use double quotes for identifier - identifiers have to be lower
t := fun1(a as "a");
plpgs
2009/5/20 Steve Prentice :
> t := fun1(1 as a); -- syntax error: "SELECT fun1(1 as $1 )"
>
> t := fun1(a as a); -- syntax error: "SELECT fun1( $1 as $1 )"
>
> On May 19, 2009, at 6:42 PM, Merlin Moncure wrote:
>
> you have a name conflict here...is it deliberate? I've l
t := fun1(1 as a); -- syntax error: "SELECT fun1(1 as
$1 )"
t := fun1(a as a); -- syntax error: "SELECT fun1( $1
as $1 )"
On May 19, 2009, at 6:42 PM, Merlin Moncure wrote:
you have a name conflict here...is it deliberate? I've learned the
hard way to always, alw
On Tue, May 19, 2009 at 5:59 PM, Steve Prentice wrote:
> I followed the past discussions regarding the syntax for named parameters
> and I am currently using Pavel Stehule's patch for named and mixed notation
> on top of the 8.4 beta.
>
> It seems the way plpgsql substitutes $1, $2, etc for the pa
I followed the past discussions regarding the syntax for named
parameters and I am currently using Pavel Stehule's patch for named
and mixed notation on top of the 8.4 beta.
It seems the way plpgsql substitutes $1, $2, etc for the parameters is
going to reduce the usefulness of this feature
