On Wed, Jun 30, 2010 at 9:51 AM, Adrian Klaver wrote:
> On Wednesday 30 June 2010 6:41:18 am Andrea Lombardoni wrote:
>> > You need to use EXECUTE for the INSERT statement as well per error:
>> >
>> > CONTEXT: SQL statement "INSERT INTO idmap (oldid, type, newid) VALUES(1,
>> > 1, 1)" PL/pgSQL f
On Wednesday 30 June 2010 6:41:18 am Andrea Lombardoni wrote:
> > You need to use EXECUTE for the INSERT statement as well per error:
> >
> > CONTEXT: SQL statement "INSERT INTO idmap (oldid, type, newid) VALUES(1,
> > 1, 1)" PL/pgSQL function "test" line 16 at SQL statement
>
> Thanks, this work
Hello
in PostgreSQL 8.2 and older you have to respect one rule - newer to
drop temp table. You don't must do it. After session end, all temp
tables are removed.
you can execute some initialisation part like
CREATE OR REPLACE FUNCTION check_tab()
RETURNS void AS $$
BEGIN
BEGIN
TRUNCATE TABL
On Wed, Jun 30, 2010 at 2:41 PM, Andrea Lombardoni wrote:
>> You need to use EXECUTE for the INSERT statement as well per error:
>>
>> CONTEXT: SQL statement "INSERT INTO idmap (oldid, type, newid) VALUES(1,
>> 1, 1)" PL/pgSQL function "test" line 16 at SQL statement
>
> Thanks, this works and s
> You need to use EXECUTE for the INSERT statement as well per error:
>
> CONTEXT: SQL statement "INSERT INTO idmap (oldid, type, newid) VALUES(1,
> 1, 1)" PL/pgSQL function "test" line 16 at SQL statement
Thanks, this works and solves my problem.
Still, I find this behaviour to be rather quirk
On Wednesday 30 June 2010 6:21:44 am Andrea Lombardoni wrote:
> >> Am I doing something wrong or is this a bug?
> >
> > The plan is cached, to avoid this problem, use dynamic SQL. In your
> > case:
> >
> > EXECUTE 'CREATE TEMPORARY TABLE idmap ...'
>
> Nice idea, but the problem persists, see log b
>> Am I doing something wrong or is this a bug?
>
> The plan is cached, to avoid this problem, use dynamic SQL. In your
> case:
>
> EXECUTE 'CREATE TEMPORARY TABLE idmap ...'
Nice idea, but the problem persists, see log below.
I am beginning to mentally place this into the 'bug' area :)
CREATE
In response to Andrea Lombardoni :
> Hello.
>
>
> The strange part is that the second time, the OID of the idmap is the
> same as the one in the first invocation!
>
> Am I doing something wrong or is this a bug?
The plan is cached, to avoid this problem, use dynamic SQL. In your
case:
EXECUTE
Hello.
I am trying to use temporary tables inside a stored procedure, but I
get a rather puzzling error.
I am currently using PostgreSQL 8.2.7 and this is my stored procedure:
CREATE OR REPLACE FUNCTION test() RETURNS bigint AS $$
DECLARE
v_oid bigint;
BEGIN
-- create tmp-table used to ma
