Tom Lane wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
