Thread: zeros in oidvector type
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. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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
> 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. The reason I ask is that there are some parts of the code that try to find the number of args by looking for the _first_ non-zero entry in the list. I changed those to look for the _last_ non-zero entry, but it sounds like that is still wrong. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The reason I ask is that there are some parts of the code that try to
> find the number of args by looking for the _first_ non-zero entry in the
> list.
Where? This is certainly broken for anything that needs to deal with
an arbitrary pg_proc entry, but it might be OK in limited contexts.
Also, if you are thinking of stuff that looks at *index* definitions
rather than *function* definitions, I think it's OK.
> I changed those to look for the _last_ non-zero entry, but it
> sounds like that is still wrong.
I'm dubious about changing something like that without fairly close
investigation and/or a known bug to fix. If those bits of code are
wrong, they were wrong before the FUNC_MAX_ARGS change ... and if
they weren't wrong, maybe they are now.
regards, tom lane