Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> One could make a good case that INDEX_MAX_KEYS should be exported along
>> with FUNC_MAX_ARGS, rather than letting people write client code that
>> assumes they are the same.

> You can determine these values by looking into the system catalogs.

You can, but that does not mean that you should. I saw how you'd made
the information_schema code induce the value of NAMEDATALEN from type
NAME's typlen, and frankly I think it's remarkably ugly and fragile.
I do *not* want to recommend that client code do similar things to
induce these values. If we do that then we'll be wiring extremely
low-level assumptions into client code forevermore. Which of these
do you want to support into the indefinite future?

current_setting("func_max_args")

(SELECT typlen/4 from pg_type where typname = 'oidvector' and
typnamespace = (select oid from pg_namespace
where nspname = 'pg_catalog'))

I realize you think that using GUC variables for this purpose is a bit
of a bastardization of the GUC concept, and I can't really argue that
it isn't. But the fact is that GUC has succeeded beyond your wildest
dreams, and you should not be surprised that people now want to
piggyback on all that nice mechanism for other purposes. If we were to
invent some other concept for "access to read-only config variables",
then we'd just have to duplicate some large fraction of the
infrastructure that already exists for GUC. Why bother?

>> * BLCKSZ

> Why would anyone be interested in that?

There was just a discussion a few days ago about the page size for large
objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
people actually *should* care about the page size of large objects I
dunno, but the fact is some of them *do* care.

>> * integer-vs-float datetime flag

> Here we should really decide on one representation in the near term.

[shrug] If push comes to shove on a single representation, we will rip
out all that int8 stuff and go back to float8. This isn't negotiable;
we can't have a system that doesn't have working datetime functionality
on a machine without int8. I don't see that happening, though, so I
think we are going to be stuck with a compile-time choice for a long
time to come.

regards, tom lane