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
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) |
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) |