On Sun, Oct 31, 2010 at 1:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> ... I assumed that TypeInfo would be >> embedded in other structs directly, rather than a pointer and palloc. > > Yeah, that would avoid the extra-pallocs complaint, although it might be > notationally a bit of a PITA in places like equalfuncs.c. I think that > would end up needing a separate COMPARE_TYPEINFO_FIELD macro instead of > being able to treat it like a Node* field. > > But I'm still wondering whether it's smart to try to promote all of this > fundamentally-auxiliary information to first-class status. It's really > unclear to me that that will end up being a net win either conceptually > or notationally.
I think this is a chicken-and-egg problem. Most of the things we use typmod for are unimportant, because typmod doesn't get propagated everywhere and therefore if you try to use it for anything that actually matters, it'll break. And on the flip side, there's no need for typmod to get propagated everywhere, because it's not used for anything all that important. Blah! It's true that if the ostensible maximum length of a string or the precision of a numeric get lost somewhere on their path through the system, probably nothing terribly awful will happen. The worst case is that those values won't be enforced someplace where the user might expect it, and that's probably avoidable in most practical cases by adding an appropriate cast. I'm not sure whether it'll also be true for collation, because that affects comparison semantics, and getting the wrong comparison semantics is worse than failing to enforce a maximum length. And we keep having these pesky requests to embed more complex information in the typmod, some of which are things that can't just be lightly thrown away because we feel like it. One of the more common ones is "an OID", so you can have things like a range over a designated base type, or a map from one base type to another base type, or whatever. Right now the on-disk representation of an array includes a 4-byte OID to store the type of the elements in that array. That's almost pure evil. Data in the database should not need to be self-identifying: imagine what our performance would look like if every integer datum in the database had to contain a tag identifying it as an integer. Granting that we have no immediate ability to change it, we should be thinking about what sort of infrastructure would be needed to eliminate this type of kludgery, or at least make it unnecessary for new types. Long story short, I'm inclined to view any data structure that is carrying only the type OID with great suspicion. If the additional information isn't needed today, it may well be tomorrow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
