mark@mark.mielke.cc writes:
> e) Generic n-byte binary data type generator. Not sure of feasibility
> of this at this point. See thread.
I don't like the idea of a generator that would have to be manually invoked,
though such a thing would be a fine tool for contrib or pgfoundry, I think it
would never be a clean enough interface for core.
On the other hand core could conceivably translate things like char(n) into
such a type generated on the fly. That is, instead of having a single char oid
it could check a cache of fixed length char(n) data types and if there isn't
one already generate one on the fly. That would be somewhat grotty of an
implementation but the user interface at least would be entirely transparent.
If one day we change things to pass around typmod database designs wouldn't
have to change at all.
(Actually Postgres can never do this for char(n), at least not as long as we
insist on making char/varchar/text locale-aware. Personally I think the
default char/varchar/text locale should be C unless you specify otherwise on a
per-column basis. But that seems to be a minority opinion. Postgres could
however do this for separate raw binary datatypes like bit(n) or bytea(n).)
In answer to your question, though my opinion carries no special weight at
all, I would suggest adding a bare bones 16-byte data type to core and a
second binary-compatible data type based on it that parsed/output as uuids.
The extended uuid libraries should only go in pgfoundry/contrib.
--
greg
