Thread: Re: request for feedback - read-only GUC variables,

Bruce, Marc, Joe:

> > > max_function_args - int
> > >    Shows the maximum number of function arguments

> > > max_index_keys - int
> > >    Shows the maximum number of index keys

Have we decoupled these two variables?   Last I checked, their values still 
had to be identical.   If they have not been decoupled and won't be in the 
forseable future, why bother with 2 variables?

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

>>>>max_function_args - int
>>>>   Shows the maximum number of function arguments
> 
>>>>max_index_keys - int
>>>>   Shows the maximum number of index keys
> 
> Have we decoupled these two variables?   Last I checked, their values still 
> had to be identical.   If they have not been decoupled and won't be in the 
> forseable future, why bother with 2 variables?

Their values are still the same, but Tom suggested we not couple them 
inextricably by giving users access to them as one variable.

Joe

Joe Conway <mail@joeconway.com> writes:
> Josh Berkus wrote:
>> Have we decoupled these two variables?

> Their values are still the same, but Tom suggested we not couple them 
> inextricably by giving users access to them as one variable.

The only reason they are the same is that pg_proc.proargtypes and
pg_index.indclass use the same fixed-length datatype, oidvector,
and so FUNC_MAX_ARGS and INDEX_MAX_KEYS must both equal the size of
this array type.

We could decouple them if we felt like it, by introducing a second
oidvector-ish datatype for one table or the other.  While I don't see
any particular reason to do so, it could happen that we want to sometime
in the future.  If we publicize to users that there is only one variable
determining both limits, it'd be a lot harder to do anything.

Basically the point is that the backend code is careful to use
FUNC_MAX_ARGS or INDEX_MAX_KEYS as appropriate, and we shouldn't
throw away that distinction at the user level.
        regards, tom lane