Re: Accessing original TupleDesc from SRF
От | Joe Conway |
---|---|
Тема | Re: Accessing original TupleDesc from SRF |
Дата | |
Msg-id | 3D6F9054.5020900@joeconway.com обсуждение исходный текст |
Ответ на | Accessing original TupleDesc from SRF (John Gray <jgray@azuli.co.uk>) |
Ответы |
Re: Accessing original TupleDesc from SRF
|
Список | pgsql-hackers |
Tom Lane wrote: > I've been thinking more about this, and wondering if we should not > only make the tupdesc available but rely more heavily on it than we > do. Most of the C-coded functions do fairly substantial pushups to > construct tupdescs that are just going to duplicate what > nodeFunctionscan already has in its back pocket. They could save some > time by just picking that up and using it. > > On the other hand, your experience yesterday with debugging a mismatched > function declaration suggests that it's still a good idea to make the > functions build the tupdesc they think they are returning. In a function which *can* know what the tupledec should look like based on independent information (contrib/tablefunc.c:crosstab), or based on a priori knowledge (guc.c:show_all_settings), then the passed in tupdesc could be used by the function to validate that it has been acceptably declared (for named types) or called (for anonymous types). But it is also interesting to let the function try to adapt to the way in which it has been called, and punt if it can't deal with it. And in some cases, like John's example, there *is* no other way. Joe
В списке pgsql-hackers по дате отправления: