Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Robert Haas <robertmh...@gmail.com> writes:
>>> I think we should break up internal into various kinds of internal
>>> depending on what kind of a thing we've actually got a pointer to.
>> Not a bad long-term project, but it's not happening in this cycle.
>> I'm not very sure how we'd go about it anyway --- for examples
>> like this, every new user-defined aggregate potentially wants its
>> own flavor of "internal", so how do we manage that?
> Can't we have them be ExtensibleNode?
No, these are data types and values of data types, not parsetree nodes.
The core problem is to teach the type system to prevent you from
sticking foo(internal) into a context where the actual value passed
will be some other kind of "internal" than it's expecting.
Having said that, another possible solution is to establish a convention
that every sort of "internal" thingy should have an ID word (with a
different magic number for each kind of thingy) that all functions check.
But I'm not convinced that that's going to be convenient to do everywhere,
and it's certainly not likely to be easier to bolt on than a bunch of new
internal-ish type OIDs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
