On Tue, 2002-07-16 at 05:43, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote:
> > > Hannu Krosing wrote:
> > > > > > The alternative would be yet another system table which would allow us
> > > > > > to support unlimited number of to/from converters for different wire
> > > > > > protocols, but it will definitely be easier to start with
> > > > > > typreceive/typsend.
> > > > >
> > > > > We can always re-add the columns them.
> > > >
> > > > But would it not be nice if we could add uniform binary protocol without
> > > > requiring initdb ?
> > >
> > > Seems impossible that would ever happen without an initdb.
> >
> > Why?
>
> It is inconceivable we would add such a feature without a major release,
> and every major release requires an initdb.
Even if we change nothing in system tables ;)
As I explained, we already have a binary protocol. What I proposed,
would make it usable between hosts with different CPU's by inserting
appropriate functions for types - without typsend(), i.e typesend=NULL
the behaviour would be exactly as it is now, but people would be free to
experiment without fatally breaking all other installations.
Technically this will probably not extend much beyond modifying function
printtup_internal in src/backend/access/common/printtup.c
/* ----------------* printtup_internal* We use a different data prefix, e.g. 'B' instead of 'D' to* indicate a tuple in
internal(binary) form.** This is largely same as printtup,except we don't use the typout func.* ----------------*/
static void
printtup_internal(HeapTuple tuple, TupleDesc typeinfo, DestReceiver
*self)
The hard part will be agreeing on the actual data format(s), but this
can be postponed by having this implementation where people can
experiment.
After looking at the code again, it seems that we must have already
solved (most) alignment issues in printtup, so the task is just agreeing
on types' on-wire representations.
------------------
Hannu
