From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Kris Jurka <books(at)ejurka(dot)com>, Alex <alex(at)meerkatsoft(dot)com>, "Lada 'Ray' Lostak" <ray(at)unreal64(dot)net>, pgsql-patches(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question) |
Date: | 2003-11-30 18:56:06 |
Message-ID: | 25148.1070218566@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
> variable -- func_max_args. Comments?
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.
I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN
* BLCKSZ
* integer-vs-float datetime flag
(Not sure about suitable GUC names for these --- func_max_args isn't out
of line as a GUC name, but surely BLCKSZ is.) NAMEDATALEN is needed for
many of the same reasons as FUNC_MAX_ARGS. BLCKSZ is probably useful
for pg_autovacuum. The datetime representation flag will be important
when people start using binary data transmission seriously --- without
it you can't tell what you'll get for a timestamp value. Essentially,
these are things we currently tell people to use pg_controldata to find
out, but that's quite an inconvenient solution.
> While I was in guc.c, I also added short_desc to the definition of the
> pg_settings view. I wasn't sure if I ought to add the long_desc too, and
> if so, should it be it's own column in the view, or be concatenated with
> short_desc -- any thoughts on that?
If it's there it should be separate. I think also there was some
feeling it should be called "extra_desc" not "long_desc".
> + /* Can't be set in postgresql.conf */
> + {"func_max_args", PGC_INTERNAL, UNGROUPED,
> + gettext_noop("Shows the compiled-in maximum number of function "
> + "arguments."),
> + NULL
> + },
> + &func_max_args,
> + FUNC_MAX_ARGS, FUNC_MAX_ARGS, FUNC_MAX_ARGS, NULL, NULL
> + },
Please set the GUC_NOT_IN_SAMPLE and GUC_DISALLOW_IN_FILE flag bits on
each of these variables, too. I know we are not using these flags for
anything yet, but we should try to get them right...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-11-30 19:05:53 | Re: pg_hba.conf problem |
Previous Message | David Nedrow | 2003-11-30 18:53:58 | pg_hba.conf problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-11-30 19:08:29 | Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: |
Previous Message | Peter Eisentraut | 2003-11-30 18:51:25 | Re: clock_timestamp() and transaction_timestamp() function |