Unused system table columns

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 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:

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@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

Rod Taylor <rbt@zort.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@zort.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@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

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@candle.pha.pa.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@candle.pha.pa.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@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