Обсуждение: SRF/dropped column bug

I see this behavior with CVS tip:

CREATE TABLE wibble (a integer, b integer);
INSERT INTO wibble VALUES (1,1);
ALTER TABLE wibble ADD COLUMN c BIGINT;
UPDATE wibble SET c = b;
ALTER TABLE wibble DROP COLUMN b;
ALTER TABLE wibble RENAME c TO b;
CREATE FUNCTION foobar() RETURNS SETOF wibble AS
'SELECT * FROM wibble' LANGUAGE SQL;

regression=# SELECT * FROM wibble; a | b
---+--- 1 | 1
(1 row)

regression=# select * from foobar(); a | b
---+--- 1 |
(1 row)

The example comes from a complaint in January 2004, at which time it 
would instead throw an ERROR:

ERROR: query-specified return row and actual function return row do not
match

I'll start digging into this, but any hints on where to look would be 
greatly appreciated.

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:
> I'll start digging into this, but any hints on where to look would be 
> greatly appreciated.

I have a couple of similar issues on the radar.  The problem probably is
some bit of code that is not accounting for dropped columns in a row
datatype --- ie, the critical part of your example is the DROP COLUMN.
        regards, tom lane

I can confirm this bug still exists in CVS.

---------------------------------------------------------------------------

Joe Conway wrote:
> I see this behavior with CVS tip:
> 
> CREATE TABLE wibble (a integer, b integer);
> INSERT INTO wibble VALUES (1,1);
> ALTER TABLE wibble ADD COLUMN c BIGINT;
> UPDATE wibble SET c = b;
> ALTER TABLE wibble DROP COLUMN b;
> ALTER TABLE wibble RENAME c TO b;
> CREATE FUNCTION foobar() RETURNS SETOF wibble AS
> 'SELECT * FROM wibble' LANGUAGE SQL;
> 
> regression=# SELECT * FROM wibble;
>   a | b
> ---+---
>   1 | 1
> (1 row)
> 
> regression=# select * from foobar();
>   a | b
> ---+---
>   1 |
> (1 row)
> 
> The example comes from a complaint in January 2004, at which time it 
> would instead throw an ERROR:
> 
> ERROR: query-specified return row and actual function return row do not
> match
> 
> I'll start digging into this, but any hints on where to look would be 
> greatly appreciated.
> 
> Thanks,
> 
> Joe
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I can confirm this bug still exists in CVS.
> 
> I have a fix for this, but cannot commit just yet as we seem to be
> having network problems again :-(

Yes, I have already beeped Marc.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I can confirm this bug still exists in CVS.

I have a fix for this, but cannot commit just yet as we seem to be
having network problems again :-(
        regards, tom lane