Re: Unused system table columns

On Tue, 2002-07-16 at 04:55, Bruce Momjian wrote:

Hannu Krosing wrote:

On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote:

The following system table columns are currently unused and don't appear
to be in the line of resurrection.

pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.probyte_pct
pg_proc.properbyte_cpu
pg_proc.propercall_cpu
pg_proc.prooutin_ratio
pg_shadow.usetrace
pg_type.typprtlen
pg_type.typreceive
pg_type.typsend

pg_type.typreceive and pg_type.typsend
are unused, but I think they should be saved for use as converters
from/to unified binary wire protocol (as their name implies ;) once we
get at it.

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 ?

If the main concern is disk space, just set them to NULL .

------------
Hannu

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

Agreed, and with schemas coming in, we are going to break so much stuff
anyway we should remove them.

---------------------------------------------------------------------------

Peter Eisentraut wrote:

The following system table columns are currently unused and don't appear
to be in the line of resurrection.

pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.probyte_pct
pg_proc.properbyte_cpu
pg_proc.propercall_cpu
pg_proc.prooutin_ratio
pg_shadow.usetrace
pg_type.typprtlen
pg_type.typreceive
pg_type.typsend

This adds up to quite some space -- on disk and on the screen. I think we
should remove them.

--
Peter Eisentraut peter_e@gmx.net

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  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, Pennsylvania 19026

Hannu Krosing wrote:

On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote:

The following system table columns are currently unused and don't appear
to be in the line of resurrection.

pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.probyte_pct
pg_proc.properbyte_cpu
pg_proc.propercall_cpu
pg_proc.prooutin_ratio
pg_shadow.usetrace
pg_type.typprtlen
pg_type.typreceive
pg_type.typsend

pg_type.typreceive and pg_type.typsend
are unused, but I think they should be saved for use as converters
from/to unified binary wire protocol (as their name implies ;) once we
get at it.

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.

-- 
  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, Pennsylvania 19026

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.

If the main concern is disk space, just set them to NULL .

Good point, but it does confuse developers.

-- 
  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, Pennsylvania 19026

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.

-- 
  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, Pennsylvania 19026

On Tue, 2002-07-16 at 11:13, Tom Lane wrote:

Hannu Krosing <hannu@tm.ee> writes:

We can always re-add the columns them.

But would it not be nice if we could add uniform binary protocol without
requiring initdb ?

That won't happen, because the existing contents of those columns are
completely useless for a binary-protocol feature.

If we do ever add such a feature, we'd be better off adding new columns
with a different name, just to avoid confusion over what's supposed to
be there. (For example: extant pg_dump scripts for user-defined types
will try to load wrong values into those columns if given a chance.

So you know some place that actually uses the values from these columns
?

Or is it just that we have told users long enough to make them same as
typinput/typoutput ?

We *must* use new names for those slots in CREATE TYPE to avoid that
pitfall, and so we might as well change the system column name too.)

Can't we just add a warning when typinput==typreceive or
typoutput==typsend, or just plain refuse to make them equal and force
people to create another function binding even if they are.

The interim solution would be to set typreceive/typsend to NULL if they
are the same as typinput/typoutput in CREATE TYPE.

-------------------
Hannu

On Tue, 2002-07-16 at 11:44, Tom Lane wrote:

Hannu Krosing <hannu@tm.ee> writes:

The interim solution would be to set typreceive/typsend to NULL if they
are the same as typinput/typoutput in CREATE TYPE.

Which still puts you right back at square one. You might as well define
two new columns that will carry the function names for binary transport.

Ok, but could this be then rename instead of removing the columns - it
will be roughly the same amount of work going through all the places
that touch pg_type. I'd even guess that renaming is _less_ work..

typsend/typreceive are hopelessly contaminated at this point, IMHO;
it'll be less work and less confusion to adopt other column names than
to try to reuse them just "because they're there".

-----------
Hannu

Hannu Krosing <hannu@tm.ee> writes:

We can always re-add the columns them.

But would it not be nice if we could add uniform binary protocol without
requiring initdb ?

That won't happen, because the existing contents of those columns are
completely useless for a binary-protocol feature.

If we do ever add such a feature, we'd be better off adding new columns
with a different name, just to avoid confusion over what's supposed to
be there. (For example: extant pg_dump scripts for user-defined types
will try to load wrong values into those columns if given a chance.
We *must* use new names for those slots in CREATE TYPE to avoid that
pitfall, and so we might as well change the system column name too.)

regards, tom lane

Hannu Krosing <hannu@tm.ee> writes:

The interim solution would be to set typreceive/typsend to NULL if they
are the same as typinput/typoutput in CREATE TYPE.

Which still puts you right back at square one. You might as well define
two new columns that will carry the function names for binary transport.

typsend/typreceive are hopelessly contaminated at this point, IMHO;
it'll be less work and less confusion to adopt other column names than
to try to reuse them just "because they're there".

regards, tom lane