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, always
2009/5/20 Steve Prentice prent...@cisco.com:
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
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);
2009/5/21 Steve Prentice prent...@cisco.com:
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 -
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
On Tue, May 19, 2009 at 5:59 PM, Steve Prentice prent...@cisco.com 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,
