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?
We already have a binary protocol, the only part I see missing for
making it _universal_ is binary representation of types + alignment
issues.
If we just write the functions for typreceive/send (mostly
identity+padding for x86, some byte swapping on SPARC (or vice versa))
and start using them when cursor is in binary mode plus we determine
minimal acceptable alignments then we are (almost?) there for output.
For input, putting in PREPARE/EXECUTE with binary argument passing will
likely need initdb (maybe not), but _temporarily_ throwing out _just_
typreceive seems weird.
> > If the main concern is disk space, just set them to NULL .
>
> Good point, but it does confuse developers.
But it confuses them _less_ than our current practice of putting unused
copies of typinput/typoutput there, and nobody seems too confused even
now ;)
And keeping them as NULL may be used to indicate than no conversion is
needed and data can be sent as-is like we do now, so we are even doing
the right thing for this scenario, all without any coding ;)
--------------
Hannu