Re: zeros in oidvector type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: zeros in oidvector type
Date
Msg-id 27521.947570110@sss.pgh.pa.us
Whole thread Raw
In response to zeros in oidvector type  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: zeros in oidvector type
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: zeros in oidvector type
Next
From: Tom Lane
Date:
Subject: INDEX_MAX_KEYS = 16 ... it works, too