Re: anonymous composite types for Table Functions (aka
От | Joe Conway |
---|---|
Тема | Re: anonymous composite types for Table Functions (aka |
Дата | |
Msg-id | 3D455FB3.3030500@joeconway.com обсуждение исходный текст |
Ответ на | anonymous composite types for Table Functions (aka SRFs) (Joe Conway <mail@joeconway.com>) |
Список | pgsql-patches |
Neil Conway wrote: > On Sun, Jul 28, 2002 at 10:24:34PM -0700, Joe Conway wrote: >>Attached are two patches to implement and document anonymous composite >>types for Table Functions, as previously proposed on HACKERS. > > Nice work! Thanks! >>1. Creates a new pg_type typtype: 'p' for pseudo type (currently either >> 'b' for base or 'c' for catalog, i.e. a class). > I think you mentioned that typtype could be renamed to typkind -- that > sounds good to me... I didn't get any feedback on that idea, so I decided to leave it alone for now. >>When creating a function you can do: >> CREATE FUNCTION foo(text) RETURNS setof RECORD ... >>When using it you can do: >> SELECT * from foo(sqlstmt) AS (f1 int, f2 text, f3 timestamp) > > Is there a reason why you can't specify the return type in the function > declaration? ISTM that for most functions, the 'AS' clause will be the > same for every usage of the function. Ahh, that's the next proposal ;-) For functions such as dblink and crosstab, mentioned in the original post, the 'AS' clause needed may be *different* every time the function is called. But specifying the composite type on function declaration would also be a good thing. In order to do that we first need to be able to create named, but stand-alone, composite types. Once we can do that, then creating an implicit named composite type (with a system generated name) on function creation should be easy. I plan to follow up with a specific proposal this week. > On a related note, it is possible for the table function to examine the > attributes it has been asked to return, right? Since the current patch > requires that every call specify the return type, it might be possible > to take advantage of that to provide semi-"polymorphic" behavior > (i.e. the function behaves differently depending on the type of data > the user asked for) Hmmm, I'll have to think about that. I don't think the current implementation has a way to pass that information to the function. We would need to modify fcinfo to carry along the run-time tupdesc if we wanted to do this. Not sure how hard it would be to do -- I'll have to look. Note that this syntax is only required when the function has been declared as returning RECORD -- if the function is declared to return some named composite type, it doesn't need or use the runtime specified structure. In that case the function *can* derive it's own tupdesc using the function return type to get the return type relid. That is how the submitted crosstab() function works. >> SELECT * from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp) > > > What does the 'f' indicate? 'f' here is the table alias. Probably would have been more clear like this: SELECT f.* from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp) >> SELECT * from foo(sqlstmt) f(f1 int, f2 text, f3 timestamp) > This form of the syntax seems a bit unclear, IMHO. It seems a bit > like two function calls. Can the 'AS' be made mandatory? Well this is currently one acceptable syntax for an alias clause, e.g. SELECT * from foo f(f1, f2, f3); is allowed. I was trying to be consistent. Anyone else have thoughts on this? Thank you for your review and comments! Joe
В списке pgsql-patches по дате отправления:
Предыдущее
От: nconway@klamath.dyndns.org (Neil Conway)Дата:
Сообщение: Re: anonymous composite types for Table Functions (aka SRFs)
Следующее
От: nconway@klamath.dyndns.org (Neil Conway)Дата:
Сообщение: aborted transaction -> error