>
> > The postgres type system is very flexible and powerful as is. What is
> > the problem this is trying to solve?
> >
> > What is the motivation for data type removal?
>
> There are many motivations involved here. I brought it up originally
> because the char2-16 types are not supported and do not provide any
> functionality over the char(),varchar(),text string types.
>
> Others suggested that since they do not care about the geometric types
> that those should be removed too.
>
> I regret bringing it up. Postgres has many unique features, and
> stripping it to become a plain vanilla SQL92 machine is a waste of time
> imo.
I agree completely. This was the point I was trying to make by asking
for the motivation. If there was a clearcut proven performance gain to be
had, I would support it. But as it is just speculation, it seems kinda
pointless to push a bunch of code around (risking breaking it) for no
very good reason.
> 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.
Exactly. Right now modules get installed by building the .so files and
then creating all the types, functions, rules, tables, indexes etc. This
is a bit more complicated than the Linux kernal 'insmod' operation. We could
easily make the situation worse through careless "whacking".
> Seems to me that Postgres' niche is at the high end of size and
> capability, not at the lightweight end competing for design wins against
> systems which don't even have transactions.
And, there are already a couple of perfectly good 'toy' database systems.
What is the point of having another one? Postgres should move toward
becoming an "industrial strength" solution.
> - Tom
Thank you for bringing some sense to this discussion.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.