Thread: Changing oidvector length
We have the oidvector and int2vector length's set in pg_type.h. Is there any way to make those values configurable from defines in config.h? If not, I will have to move the defines to postgres.h so people can not change them. Maybe that is a better place for them anyway. -- 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:
> We have the oidvector and int2vector length's set in pg_type.h. Is
> there any way to make those values configurable from defines in
> config.h?
> If not, I will have to move the defines to postgres.h so people can not
> change them. Maybe that is a better place for them anyway.
Actually, I suspect they should be in postgres_ext.h, which is where
NAMEDATALEN is. All of these values are potentially visible to code
outside Postgres, so postgres_ext.h seems like the right place.
config.h would be appropriate for something you could tweak without
changing the external API of Postgres...
regards, tom lane
You have:
#define FUNC_MAX_ARGS (INDEX_MAX_KEYS+1)
This is WRONG, I'm pretty sure --- FUNC_MAX_ARGS should be the same
as the length of oidvector.
User-declared functions can definitely only have as many args as there
are slots in oidvector, because that's all the room there is to declare
them in pg_proc.
You may have gotten confused because fmgr.c allowed 9 args to be passed,
even though there's no way to declare such a function; I think this was
a hack to support some special system usage --- possibly selectivity
estimators had 9 args at one time. (They don't now, so the 9th-arg
support was dead code as far as I can tell.) But if we are going to
increase the default MAX_ARGS above 8 then the issue goes away anyway,
and there's no need for fmgr.c to support more args than can normally
be declared.
regards, tom lane
> You have: > > #define FUNC_MAX_ARGS (INDEX_MAX_KEYS+1) > > This is WRONG, I'm pretty sure --- FUNC_MAX_ARGS should be the same > as the length of oidvector. > > User-declared functions can definitely only have as many args as there > are slots in oidvector, because that's all the room there is to declare > them in pg_proc. I was going to ask about that. The original value for this was 9, while oid8 was only 8 long. When I went to 16, FUNC_MAX_ARGS has to 17 or initdb fails on int4in. No idea why, and want to ask if anyone knows why this is required. I know it should be 16, but I can't figure out why it doesn't work at 16, only at 17. > > You may have gotten confused because fmgr.c allowed 9 args to be passed, > even though there's no way to declare such a function; I think this was > a hack to support some special system usage --- possibly selectivity btbuild, I believe. > estimators had 9 args at one time. (They don't now, so the 9th-arg > support was dead code as far as I can tell.) But if we are going to > increase the default MAX_ARGS above 8 then the issue goes away anyway, > and there's no need for fmgr.c to support more args than can normally > be declared. -- 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:
>> You may have gotten confused because fmgr.c allowed 9 args to be passed,
>> even though there's no way to declare such a function; I think this was
>> a hack to support some special system usage --- possibly selectivity
>
> btbuild, I believe.
Ah, you are right (it just blew up on me when I tried it at eight ;-)).
>> But if we are going to
>> increase the default MAX_ARGS above 8 then the issue goes away anyway,
>> and there's no need for fmgr.c to support more args than can normally
>> be declared.
This still holds though --- we will just require INDEX_MAX_ARGS to be
at least 9 from here on out...
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> You may have gotten confused because fmgr.c allowed 9 args to be passed, > >> even though there's no way to declare such a function; I think this was > >> a hack to support some special system usage --- possibly selectivity > > > > btbuild, I believe. > > Ah, you are right (it just blew up on me when I tried it at eight ;-)). > > >> But if we are going to > >> increase the default MAX_ARGS above 8 then the issue goes away anyway, > >> and there's no need for fmgr.c to support more args than can normally > >> be declared. > > This still holds though --- we will just require INDEX_MAX_ARGS to be > at least 9 from here on out... But it bombs on 16. -- 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