2010/10/31 Robert Haas <robertmh...@gmail.com>: > 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! >
yes, there is a few good possible features that's needs a better using of typmod a) typmod for OUT varibles b) enhanced polymorphic types - ANYELEMENT(x) Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
