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, Pennsylvania 19026

Mon, 10 Jan 2000 13:51:17 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Changing oidvector length
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

Mon, 10 Jan 2000 19:35:57 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Changing oidvector length 
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

Mon, 10 Jan 2000 19:52:46 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Changing oidvector length 
> 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, Pennsylvania 19026

Mon, 10 Jan 2000 20:25:14 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Changing oidvector length
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

Mon, 10 Jan 2000 21:25:51 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Changing oidvector length 
> 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, Pennsylvania 19026

Mon, 10 Jan 2000 21:34:48 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Changing oidvector length