Unused system table columns

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.

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

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(at)gmx(dot)net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

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

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(at)gmx(dot)net

For all intent and purpose, pg_index.indisprimary can be added to that
list. Can't make a primary key without a pg_constraint entry.

The below are also reported unused by the documentation:

pg_class.relukeys
pg_class.relfkeys
pg_class.relrefs
pg_index.indisclustered
pg_index.indreference

On Mon, 2002-07-15 at 18: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
>
> This adds up to quite some space -- on disk and on the screen. I think we
> should remove them.

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

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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:
> 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.

I just can't imagine adding anything like that in a minor release. In
fact, I most would object to adding it in a minor release because we
don't add features in a minor release. Now, if you want it kept because
you may want to work in that area, we can surely do that.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)tm(dot)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(at)tm(dot)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

Rod Taylor <rbt(at)zort(dot)ca> writes:
> For all intent and purpose, pg_index.indisprimary can be added to that
> list. Can't make a primary key without a pg_constraint entry.

I disagree. For one thing, there are clients that look at that column.
There's no percentage in breaking them to gain zero (and it will be
zero, because of alignment considerations...)

indisclustered is currently pretty useless, but may become less so
if CLUSTER gets upgraded to usefulness, so I'm not in favor of deleting
that either.

No strong attachment to the other stuff mentioned so far.

regards, tom lane

Tom Lane wrote:
> Rod Taylor <rbt(at)zort(dot)ca> writes:
> > For all intent and purpose, pg_index.indisprimary can be added to that
> > list. Can't make a primary key without a pg_constraint entry.
>
> I disagree. For one thing, there are clients that look at that column.
> There's no percentage in breaking them to gain zero (and it will be
> zero, because of alignment considerations...)

Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.

>
> indisclustered is currently pretty useless, but may become less so
> if CLUSTER gets upgraded to usefulness, so I'm not in favor of deleting
> that either.

Yea, I can see that being useful some day.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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 <hannu(at)tm(dot)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

> > I disagree. For one thing, there are clients that look at that column.
> > There's no percentage in breaking them to gain zero (and it will be
> > zero, because of alignment considerations...)
>
> Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.

Not to mention phpPgAdmin, psql, pg_dump, TOra, pgadmin, etc.

Chris

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.

Eh? It is, AFAIK.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.
>
> Eh? It is, AFAIK.

Oh, I can't remember if it was fixed or broken. Certainly it is nice to
have for apps like pgaccess.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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 <hannu(at)tm(dot)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