Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend