Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Can't we have them be ExtensibleNode?
>
> No, these are data types and values of data types, not parsetree nodes.
Ah, right.
> 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.
Makes sense as a safety measure.
> 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.
I think the magic number is a lot more convenient than new type OIDs.
As the number of internal types grows, it will become a nuisance,
considering that you need to add boilerplate for in/out/send/recv
functions, document it as a pseudotype, yadda yadda yadda. Some central
place to define the internal numbers to ensure uniqueness, akin to
duplicate_oids, is probably a necessity, though, which may be a bit too
much scripting to be indulging in, this late in the cycle.
I suppose we could have done pg_ddl_command this way, but it's already
in 9.5 so it's probably too late for that.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services