Joe Conway <[EMAIL PROTECTED]> writes:
> The question is how to best bootstrap this new function. In order to
> create the pg_proc entry I need the return type oid. If I understand
> correctly, in order to get a composite return type, with a known oid, I
> would need to create a bootstrapped relation and the corresponding
> bootstrapped pg_type entry.
Well, we're not doing that; and I see no good reason to make the thing
be a builtin function at all. Since it's just an example, it can very
well be a contrib item with a creation script. Probably *should* be,
in fact, because dynamically created functions are what other people are
going to be building; an example of how to do it as a builtin function
isn't as helpful.
Further down the road it may be that we'll get around to allowing
freestanding composite types (ie, ones with no associated table).
That would make it less painful to have builtin functions returning
tuples --- though not by a lot, since you'd still have to manufacture
pg_type and pg_attribute rows for 'em by hand. I'm not in a hurry to do
that in any case, because of the extent of restructuring of pg_class,
pg_type, and pg_attribute that would be needed.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
