Обсуждение: Using textin/textout vs. scribbling around

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?

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:
> 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).

Other than contrib, what places do you have in mind?

> The background is that the internal format might change sometime when
> more locale features are implemented (see recent idea).  Is this a
> good idea?

Not sure.  The I/O interface --- specifically the dependency on
null-terminated strings --- isn't necessarily graven on stone tablets
either.  It could end up that this change adds more future work rather
than preventing it.

I'd be inclined to wait until we actually do change the internal
representation of text, if we do so, before expending this effort.
        regards, tom lane

I am tempted to replace all attempts to build text data on your own (with  VARDATA, VARHDRSZ, etc.) with proper
callsto textin/textout in all places  that can't claim to be truly internal (especially all contrib).  The  background
isthat the internal format might change sometime when more  locale features are implemented (see recent idea).  Is this
agood 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

> 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.

Most of the entension API's are written by commercial companies with
closed-source code, so they have to have an API to interface to their
programs.  Also, the API's are often unsuccessful because they are
either unnecessarily complex or can't adapt to new features.  We ship
the code and I think an API could actually hurt us in the long run.

For example, when we added TOAST, it changed how we had to do a few
things.  No one could have anticipated it, and with a few changes all
the plugins worked just like native code.  I don't think an API would
have helped, or if it did, it would have necessiated overhead not
present in the native types.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026