Re: anonymous composite types for Table Functions (aka SRFs)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: anonymous composite types for Table Functions (aka SRFs)
Date: 2002-08-05 00:41:37
Message-ID: 24118.1028508097@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I can back it out, but it may cause the same problems when I try to
> apply it later. It was submitted July 28, added to the patch queue
> August 1, and applied today, August 4. I don't remember anyone saying
> they wanted to review it. It is an extension to an earlier patch.

Let me just put down a marker now: anything that large I want to review.

I'm currently trying to deal with the fact that the patch broke
functions that return domain types. For example:

regression=# create function foo() returns setof int as
regression-# 'select unique1 from tenk1 limit 10' language sql;
CREATE FUNCTION
regression=# create domain myint as int;
CREATE DOMAIN
regression=# create function myfoo() returns setof myint as
regression-# 'select unique1 from tenk1 limit 10' language sql;
ERROR: Unknown kind of return type specified for function

The alias hacking seems to have a few holes as well:

regression=# select * from foo();
foo
------
8800
1891
3420
...

(fine)

regression=# select * from foo() as z;
foo
------
8800
1891
3420
9850
...

(hm, what happened to the alias?)

regression=# select * from foo() as z(a int);
foo
------
8800
1891
3420
9850
7164
...

(again, what happened to the alias? Column name should be a)

regression=# select * from foo() as z(a int8);
foo
------
8800
1891
3420
9850

(definitely not cool)

> If we back it out and delay it more, won't the patch become even harder
> to apply? Let me know.

Right now the last thing we need is more CVS churn. Let's see if it can
be fixed. Joe, you need to reconsider the relationship between alias
clauses and this feature, and also reconsider checking of the types.

> One trick I use for patch problems is this: If a patch doesn't apply,
> and it is too hard to manually merge, I generate a diff via CVS of the
> last change to the file, save it, reverse out that diff, then apply the
> rejected part of the new patch, _then_ apply the CVS diff I
> generated.

It'd be kind of nice if you actually tested the result. Once again
you've applied a large patch without bothering to see if it compiled,
let alone passed regression.

Yes, I'm feeling annoyed this evening...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-08-05 00:47:51 Re: anonymous composite types for Table Functions (aka
Previous Message Bruce Momjian 2002-08-05 00:26:44 Re: anonymous composite types for Table Functions (aka SRFs)

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2002-08-05 00:47:51 Re: anonymous composite types for Table Functions (aka
Previous Message Bruce Momjian 2002-08-05 00:26:44 Re: anonymous composite types for Table Functions (aka SRFs)