Skip site navigation (1) Skip section navigation (2)

Re: EXECUTE USING for plpgsql (for 8.4)

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: EXECUTE USING for plpgsql (for 8.4)
Date: 2007-10-23 20:18:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Pavel Stehule wrote:
>> This doesn't work:
>> create function exc_using(varchar) returns varchar
>> as $$
>>  declare v varchar;
>> begin
>>   execute 'select upper($1)' into v using ('aa');
> it cannot work. Your parameter is row. 

Really? "execute 'select upper($1)' into v using ('aa'::varchar);"
works, as does "execute 'select $1 + 1' into v using (12345);".

> But into v using 'aaa' doesn't work too :(
> ERROR:  failed to find conversion function from unknown to text
> CONTEXT:  SQL statement "select upper($1)"
> you have to specify type: use argument, variable or casting
> .... using text 'aaa'; or select upper($1::text)
> It is question for Tom. Why prepared statement cannot cast from literal to text

Yeah, I suppose we'll just live with that. Using literals as arguments
is kind of pointless anyway, since you could as well put the literal in
the query as well and not bother with the USING.

>> I also noted that the patch makes USING a keyword. Not sure if we care
>> about that or not.
> I am afraid to change well know syntax (SQL/PSM use it in same context too).

No I think the syntax is fine. I'm just wondering if it really has to be
a reserved keyword to implement that syntax. Looking at the plpgsql
grammar close, we don't categorize keywords like we do in the main
grammar, so maybe what I'm saying doesn't make any sense.

  Heikki Linnakangas

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-10-23 21:40:37
Subject: Re: uuid.h on Debian
Previous:From: Magnus HaganderDate: 2007-10-23 18:07:41
Subject: Re: Win32: Minimising desktop heap usage

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group