> If any restructuring happens which removes, or makes optional, some of
> the fundamental types, it should be accomplished so that the types can
> be added in transparently, from a single set of source code, during
> build time or after. OIDs would have to be assigned, presumably, and the
> hardcoding of the function lookups for builtin types must somehow be
> done incrementally. Probably needs more than this to be done right, and
> without careful planning and implementation we will be taking a big step
> backwards.
This whole discussion reminds me of someone who thinks he is getting low
gas milage because his tire pressure is low, when in fact, he has a
whole in his gas tank. We have some major holes to plug, but they are
hard to see. People see the tire pressure/pg_class table, and think the
database can be improved. You could double the size of the system
tables, or the binary, and see no performance change. Make them
10-times bigger, and see if you find a difference.
Aren't there enough serious issues on the TODO list for people? These
are actual complaints/bugs or requests from users, not pie-in-the-sky
wouldn't-it-be-nice-if-we-had ideas.
I had a private e-mail conversation with someone, and they mentioned
that we seem to be mired in micro-optimizations, that really are not
going to do us any significant good. I see his point.
Look at the TCL/TK mess I got into just trying to get that to work, and
removing the stuff that checked for specific tck/tk version numbers.
Can you imagine the effort we will go through ripping out types?
Another thing. It is the type extensibility that makes us more complex,
not the types themselves.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)