Re: Unused system table columns

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unused system table columns
Date: 2002-07-15 22:41:01
Message-ID: 1026772862.2350.95.camel@rh72.home.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-07-15 22:51:08 getopt bug
Previous Message Bruce Momjian 2002-07-15 22:40:18 getopt_long search in configure