I am tempted to replace all attempts to build text data on your own (with
VARDATA, VARHDRSZ, etc.) with proper calls to textin/textout in all places
that can't claim to be truly internal (especially all contrib). The
background is that the internal format might change sometime when more
locale features are implemented (see recent idea). Is this a good idea?
I would be in favor of this for the following reasons. One of the
great advantages of PostgreSQL is that adding new types is relatively
straightforward. In many cases new types could be coded largely in
terms of preexisting types. An example I am facing currently involves
the problem of constructing basically a TEXT type with rather unusual
parsing and output semantics. If a reasonably well-encapsulated
version of the TEXT type existed--including header files with the
right granularity and with the right functions provided in an
installed library--the natural means of providing the new type we need
would be to simply define a type with different *in/*out functions
implemented over an instance of the TEXT internal data
representation.
Peter's suggestion appears to be a natural step towards the goal of
being able to provide a defined interface that could be used for
extensions. The concern that the _external_ format might change seems
counter to the effort of providing a stable platform for extending
PostgreSQL. If there is a serious possibility that this might occur,
and because of that we cannot provide any external interface to the
predefined types, then the well-known advantages of composing software
modules from well-defined and well-tested components will be largely
lost for anyone wishing to rapidly extend the system.
Cheers,
Brook
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
