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

Re: alter table tablename add column - breaks pl/pgsql function returns tablename

From: Palle Girgensohn <girgen(at)pingpong(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Palle Girgensohn <girgen(at)freebsd(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: alter table tablename add column - breaks pl/pgsql function returns tablename
Date: 2012-11-05 22:52:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

5 nov 2012 kl. 22:23 skrev Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Palle Girgensohn <girgen(at)pingpong(dot)net> writes:
>> Please note that this problem does not go away by disconnecting and reconnecting, and other sessions get the error immediately, so the claim that it is bound to a session is false.
> Huh?  The test case you provided certainly doesn't exhibit any such
> behavior.  I get
> regression=# SELECT * FROM test_func();
> ERROR:  wrong record type supplied in RETURN NEXT
> CONTEXT:  PL/pgSQL function test_func() line 6 at RETURN NEXT
> regression=# \c -
> You are now connected to database "regression" as user "postgres".
> regression=# SELECT * FROM test_func();
> id | foo 
> ----+-----
>  1 |    
> (1 row)
>            regards, tom lane

Ah, sorry. Other sessions get the error immediately as well though. Would input parameters matter, or is it just the return type? I'll see if I can find a test case that breaks permanently, but I'm probably mistaken about that bit then. 

In response to


pgsql-hackers by date

Next:From: Jeff JanesDate: 2012-11-05 23:15:30
Subject: Re: Pg_upgrade speed for many tables
Previous:From: Josh BerkusDate: 2012-11-05 22:47:58
Subject: Re: What are the advantages of not being able to access multiple databases with one connection?

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