Joe Conway <mail@joeconway.com> writes:
> I'm thinking about next steps for SRFs and looking for input. ... At
> this point I know of several things which need to be done (or at least I
> think they are desirable):
> 1. Documentation -- it wasn't clear if Joel Burton was going to have
> time to contribute something here, but if not, I'll start working on
> this next. Any guidance as to which section of the docs this should go in?
There is related material currently in the SQL-functions section of the
programmer's guide. This should perhaps be moved to someplace where
it's more clearly relevant to all types of functions. On the other hand
it's awfully nice to be able to show simple examples, so I'm not sure we
want to divorce the material from SQL functions entirely.
> 3. PL/pgSQL support for returning sets -- this seems to me like an
> important item if SRFs are to be useful to the masses. Any pointers on
> how to approach this would be appreciated.
Does Oracle's pl/sql support this? If so what does it look like?
> 6. Support for named composite types that don't have a table tied to them.
I agree that this is bottom priority. It doesn't really add any
functionality (since a dummy table doesn't cost much of anything).
And a clean solution would require major rearchitecting of the system
tables --- pg_attribute rows would need to be tied to pg_type rows for
composite types, not to pg_class rows. While this would be quite doable
considering the backend alone, I'm not excited about the prospect of
breaking every catalog-examining client in sight. Another interesting
question is whether inheritance now applies to types rather than tables,
and if so what does that imply?
(OTOH one could make a good argument that now is the time to do it
if we're ever gonna do it --- clients that are not schema-aware will
be badly in need of work anyway for 7.3...)
regards, tom lane
