Re: zeros in oidvector type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: zeros in oidvector type
Date: 2000-01-11 05:55:10
Message-ID: 27521.947570110@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom, why are the non-trailing zeros in the *vector types as initialized
> in the catalog/*.h files.

> You mentioned you knew what they meant.

In pg_proc's proargtypes entries, a zero in a valid argument position
(ie, one of the first 'pronargs' positions) can mean either "any type
is acceptable" or "opaque argument type" (not sure if those are quite
the same thing or not!) or "C string input to a datatype's typinput
conversion routine" (definitely not the same thing).

The entries in pg_proc.h call out these zeroes explicitly even when
they are trailing arguments --- generally, the number of values shown
in the proargtypes column should equal pronargs.

I don't think there's any good way for oidvectorout to duplicate that
string, if that's what you were wondering about; oidvectorout has no
access to the value of pronargs.

Someday I would like to replace these special meanings of "zero type
oid" with definite nonzero type OIDs (this has been discussed before,
at least for the C-string case). Then the issue goes away.

BTW, I just managed to pass the regression tests with INDEX_MAX_KEYS
set to 10. Will commit a couple more fixes momentarily. Next thing
is to see if functions and indexes with >8 args actually work...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-01-11 06:03:22 INDEX_MAX_KEYS = 16 ... it works, too
Previous Message Bruce Momjian 2000-01-11 05:14:50 zeros in oidvector type