Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Bruce Momjian wrote: Peter Eisentraut wrote: Joe Conway writes: Any more thoughts on block_size (or page_size)? It's always been some variant spelling of "block size", and I see no reason to change the terminology. Yes, that is from a coder's perspective, but from the user/admin perspective, it seems more like page, and in fact we probably would call it page if we were starting from scratch. Hmm, I don't feel strongly either way on this, but I guess I lean toward block_size myself. Any other opinions out there? block_size or page_size or something else? Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Peter Eisentraut wrote: > Joe Conway writes: > > > Any more thoughts on block_size (or page_size)? > > It's always been some variant spelling of "block size", and I see no > reason to change the terminology. Yes, that is from a coder's perspective, but from the user/admin perspective, it seems more like page, and in fact we probably would call it page if we were starting from scratch. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway writes: > Any more thoughts on block_size (or page_size)? It's always been some variant spelling of "block size", and I see no reason to change the terminology. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Bruce Momjian wrote: Any more thoughts on block_size (or page_size)? When I think of block size I think of disk blocks, and when I think of pages I think of memory pages. Unfortunately, neither is a database page. I guess my point is that we have heap pages and index pages, but no one calls them heap blocks or index blocks, and I am not sure I would know what they meant if they said that. OK, I'll go with "page_size". Thanks, Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway wrote:
> Bruce Momjian wrote:
> > Joe Conway wrote:
> >>The description is a statement because the option is boolean, i.e. the
> >>statement "Datetimes are integer based" is either "true" or "false"
> >>("on" or "off", etc). How stongly do you feel about it? I don't think
> >>"integer_datetime_storage" is accurate in any case.
> >
> > Not strongly. Keep it unchanged.
> >
>
> Any more thoughts on block_size (or page_size)?
When I think of block size I think of disk blocks, and when I think of
pages I think of memory pages. Unfortunately, neither is a database
page.
I guess my point is that we have heap pages and index pages, but no one
calls them heap blocks or index blocks, and I am not sure I would know
what they meant if they said that.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Bruce Momjian wrote:
Joe Conway wrote:
The description is a statement because the option is boolean, i.e. the
statement "Datetimes are integer based" is either "true" or "false"
("on" or "off", etc). How stongly do you feel about it? I don't think
"integer_datetime_storage" is accurate in any case.
Not strongly. Keep it unchanged.
Any more thoughts on block_size (or page_size)?
Thanks,
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway wrote:
> >>name | func_max_args
> >>name | index_max_keys
> > Should that be max_func_args and max_index_args? Seems more natural.
> > Should we spell out function? Probably. We already have
> > check_*function*_bodies.
>
> Agreed. Now:
> name | max_function_args
> name | max_identifier_length
> name | max_index_keys
Nice.
> >>name | integer_datetimes
> >>short_desc | Datetimes are integer based
> >
> > This one has me confused. "Datetimes are integer based" is a statement,
> > as is the variable name. Should it be "integer_datetime_storage" or
> > something else?
>
> Well the configure option is:
> --enable-integer-datetimes
> so "integer_datetimes" seemed natural to me.
>
> The description is a statement because the option is boolean, i.e. the
> statement "Datetimes are integer based" is either "true" or "false"
> ("on" or "off", etc). How stongly do you feel about it? I don't think
> "integer_datetime_storage" is accurate in any case.
Not strongly. Keep it unchanged.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> 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. > Maybe we should provide specific functions to access this information, so > client applications don't have to hardcode these formulas. That's exactly what this thread is about: current_setting() is the proposed access function ... I'm not convinced that large object pagesize is interesting enough to deserve its own GUC variable, but if someone wanted to make that case I'm certainly open to listening. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was:
Tom Lane writes: > 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. Maybe we should provide specific functions to access this information, so client applications don't have to hardcode these formulas. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Bruce Momjian wrote:
Joe Conway wrote:
name | block_size
OK. Should that be page_size? Not sure but block size sounds more like
a hardware setting. I know we call it BLCKSZ in our code but page size
seems more appropriate. Not sure.
Seems like block_size is more appropriate to me. Any other opinions out
there? In bufpage.h I see this description of a page:
/*
* A postgres disk page is an abstraction layered on top of a postgres
* disk block (which is simply a unit of i/o, see block.h).
I guess the ral question is whether the uses for this information really
care about block size or page size -- i.e. if they weren't the same,
which would be the one you want to know?
name | func_max_args
name | index_max_keys
Should that be max_func_args and max_index_args? Seems more natural.
Should we spell out function? Probably. We already have
check_*function*_bodies.
Agreed. Now:
name | max_function_args
name | max_identifier_length
name | max_index_keys
name | integer_datetimes
short_desc | Datetimes are integer based
This one has me confused. "Datetimes are integer based" is a statement,
as is the variable name. Should it be "integer_datetime_storage" or
something else?
Well the configure option is:
--enable-integer-datetimes
so "integer_datetimes" seemed natural to me.
The description is a statement because the option is boolean, i.e. the
statement "Datetimes are integer based" is either "true" or "false"
("on" or "off", etc). How stongly do you feel about it? I don't think
"integer_datetime_storage" is accurate in any case.
name | name_data_len
Is "name" a good description, or is "identifier" better, identifier_length?
Agreed -- see above.
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway wrote: > Tom Lane wrote: > > 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 > > OK, the attached includes the above -- result looks like: > > regression=# select * from pg_settings where category like 'Compile%'; > -[ RECORD 1 ]-- > name | block_size OK. Should that be page_size? Not sure but block size sounds more like a hardware setting. I know we call it BLCKSZ in our code but page size seems more appropriate. Not sure. > name | func_max_args > name | index_max_keys Should that be max_func_args and max_index_args? Seems more natural. Should we spell out function? Probably. We already have check_*function*_bodies. > name | integer_datetimes > short_desc | Datetimes are integer based This one has me confused. "Datetimes are integer based" is a statement, as is the variable name. Should it be "integer_datetime_storage" or something else? > name | name_data_len Is "name" a good description, or is "identifier" better, identifier_length? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway <[EMAIL PROTECTED]> writes: > It will require an initdb -- should I hold off for other > pending changes also requiring initdb? No, there's no particular reason to avoid initdbs during development cycles. That's why we have catversion in the first place ... regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Tom Lane wrote: Perhaps the GUC variable name should be max_name_len or some such. Also, should func_max_args and index_max_keys become max_func_args and max_index_keys? That sounds good to me: -[ RECORD 3 ]-- name | max_func_args setting| 32 -[ RECORD 4 ]-- name | max_index_keys setting| 32 -[ RECORD 5 ]-- name | max_name_len setting| 63 I'll finish up the docs and commit this tomorrow, barring strong complaints. It will require an initdb -- should I hold off for other pending changes also requiring initdb? Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway <[EMAIL PROTECTED]> writes: > name | name_data_len > setting| 63 > short_desc | Shows the maximum identifier length Defining the value as NAMEDATALEN-1 is reasonable (I was thinking of suggesting that myself), but it seems like a recipe for confusion to use name_data_len to refer to NAMEDATALEN-1. Perhaps the GUC variable name should be max_name_len or some such. Also, should func_max_args and index_max_keys become max_func_args and max_index_keys? I'm not all that concerned about the names personally, but I want to forestall any temptation for Bruce to start renaming these values later, as he's felt free to do in the past ;-). My expectation is that the names of these GUC variables will get embedded into client-side code fairly quickly, and so it will not do to fool around with the names later. We must decide what the naming convention is and then stick to it. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Tom Lane wrote:
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
OK, the attached includes the above -- result looks like:
regression=# select * from pg_settings where category like 'Compile%';
-[ RECORD 1 ]--
name | block_size
setting| 8192
category | Compiled-in Options
short_desc | Shows size of a disk block
extra_desc |
context| internal
vartype| integer
source | default
min_val| 8192
max_val| 8192
-[ RECORD 2 ]--
name | func_max_args
setting| 32
category | Compiled-in Options
short_desc | Shows the maximum number of function arguments
extra_desc |
context| internal
vartype| integer
source | default
min_val| 32
max_val| 32
-[ RECORD 3 ]--
name | index_max_keys
setting| 32
category | Compiled-in Options
short_desc | Shows the maximum number of index keys
extra_desc |
context| internal
vartype| integer
source | default
min_val| 32
max_val| 32
-[ RECORD 4 ]--
name | integer_datetimes
setting| on
category | Compiled-in Options
short_desc | Datetimes are integer based
extra_desc |
context| internal
vartype| bool
source | default
min_val|
max_val|
-[ RECORD 5 ]--
name | name_data_len
setting| 63
category | Compiled-in Options
short_desc | Shows the maximum identifier length
extra_desc |
context| internal
vartype| integer
source | default
min_val| 63
max_val| 63
If it's there it should be separate. I think also there was some
feeling it should be called "extra_desc" not "long_desc".
Done. Also added "category" which displays config_group_names[conf->group]
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...
Done.
I'll update the docs once I'm sure we're done iterating on these changes.
Any further comments?
Joe
Index: src/backend/catalog/system_views.sql
===
RCS file: /cvsroot/pgsql-server/src/backend/catalog/system_views.sql,v
retrieving revision 1.3
diff -c -r1.3 system_views.sql
*** src/backend/catalog/system_views.sql29 Nov 2003 22:39:40 - 1.3
--- src/backend/catalog/system_views.sql1 Dec 2003 05:49:21 -
***
*** 260,267
CREATE VIEW pg_settings AS
SELECT *
FROM pg_show_all_settings() AS A
! (name text, setting text, context text, vartype text,
! source text, min_val text, max_val text);
CREATE RULE pg_settings_u AS
ON UPDATE TO pg_settings
--- 260,267
CREATE VIEW pg_settings AS
SELECT *
FROM pg_show_all_settings() AS A
! (name text, setting text, category text, short_desc text, extra_desc text,
! context text, vartype text, source text, min_val text, max_val text);
CREATE RULE pg_settings_u AS
ON UPDATE TO pg_settings
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.173
diff -c -r1.173 guc.c
*** src/backend/utils/misc/guc.c1 Dec 2003 03:55:21 - 1.173
--- src/backend/utils/misc/guc.c1 Dec 2003 05:49:23 -
***
*** 156,162
static char *session_authorization_string;
static char *timezone_string;
static char *XactIsoLevel_string;
!
/* Macros for freeing malloc'd pointers only if appropriate to do so */
/* Some of these tests are probably redundant, but be safe ... */
--- 156,166
static char *session_authorization_string;
static char *timezone_string;
static char *XactIsoLevel_string;
! static intfunc_max_args;
! static intindex_max_keys;
! static intname_data_len;
! static intblock_size;
! static bool integer_datetimes;
/* Macros for freeing malloc'd pointers only if appropriate to do so */
/* Some of these tests are probably redundant, but be safe ... */
***
*** 302,307
--- 306,313
gettext_noop("Version and Platform Compatibility / Other Platforms and
Clients"),
/* DEVELOPER_OPTIONS */
gettext_noop("Developer Options"),
+ /* COMPILE_OPTIONS */
+ gettext_noop("Compiled-in Options"),
/* help_config wants this array to be null-terminated */
NULL
};
***
*** 832,837
--- 838,857
tru
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was:
Peter Eisentraut wrote: > 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. How, count? Seems we should give an easy API. > > I was intending to propose that we also export the following as > > read-only variables: > > * NAMEDATALEN > > And this as well. Again, why not make it easy. > > * BLCKSZ > > Why would anyone be interested in that? Performance/admin tools might need this --- you need it to get the disk size based on the number of pages recorded in pg_class. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
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
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was:
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. > I was intending to propose that we also export the following as > read-only variables: > * NAMEDATALEN And this as well. > * BLCKSZ Why would anyone be interested in that? > * integer-vs-float datetime flag Here we should really decide on one representation in the near term. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
Joe Conway <[EMAIL PROTECTED]> 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
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
Tom Lane wrote:
I was thinking of proposing that we provide something just about like
that as a standard function (written in C, not in plpgsql, so that it
would be available whether or not you'd installed plpgsql). There are
some places in the information_schema that desperately need it ---
right now, the value of FUNC_MAX_ARGS is effectively hard-wired into
some of the information_schema views, which means they are broken if
one changes that #define. We could fix this if we had a function like
the above and exported FUNC_MAX_ARGS as a read-only GUC variable.
First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
variable -- func_max_args. Comments?
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?
Current output looks like this:
regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'func_max_args';
-[ RECORD 1 ]---
name | func_max_args
setting| 32
short_desc | Shows the compiled-in maximum number of function arguments.
context| internal
vartype| integer
source | default
min_val| 32
max_val| 32
This will require a catalog version bump when I apply it (not done in
the attached patch).
Joe
Index: src/backend/catalog/system_views.sql
===
RCS file: /cvsroot/pgsql-server/src/backend/catalog/system_views.sql,v
retrieving revision 1.3
diff -c -r1.3 system_views.sql
*** src/backend/catalog/system_views.sql29 Nov 2003 22:39:40 - 1.3
--- src/backend/catalog/system_views.sql30 Nov 2003 04:58:51 -
***
*** 260,266
CREATE VIEW pg_settings AS
SELECT *
FROM pg_show_all_settings() AS A
! (name text, setting text, context text, vartype text,
source text, min_val text, max_val text);
CREATE RULE pg_settings_u AS
--- 260,266
CREATE VIEW pg_settings AS
SELECT *
FROM pg_show_all_settings() AS A
! (name text, setting text, short_desc text, context text, vartype text,
source text, min_val text, max_val text);
CREATE RULE pg_settings_u AS
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.172
diff -c -r1.172 guc.c
*** src/backend/utils/misc/guc.c29 Nov 2003 19:52:03 - 1.172
--- src/backend/utils/misc/guc.c30 Nov 2003 04:58:52 -
***
*** 156,161
--- 156,162
static char *session_authorization_string;
static char *timezone_string;
static char *XactIsoLevel_string;
+ static intfunc_max_args;
/* Macros for freeing malloc'd pointers only if appropriate to do so */
***
*** 862,867
--- 863,878
8, 1, INT_MAX, NULL, NULL
},
{
+ /* 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
+ },
+ {
{"join_collapse_limit", PGC_USERSET, QUERY_TUNING_OTHER,
gettext_noop("Sets the FROM-list size beyond which JOIN
constructs are not "
"flattened."),
***
*** 3468,3481
/* setting : use _ShowOption in order to avoid duplicating the logic */
values[1] = _ShowOption(conf);
/* context */
! values[2] = GucContext_Names[conf->context];
/* vartype */
! values[3] = config_type_names[conf->vartype];
/* source */
! values[4] = GucSource_Names[conf->source];
/* now get the type specifc attributes */
switch (conf->vartype)
--- 3479,3495
/* setting : use _ShowOption in order to avoid duplicating the logic */
values[1] = _ShowOption(conf);
+ /* short_desc */
+ values[2] = conf->short_desc;
+
/* context */
! values[3] = GucContext_Names[conf->context];
/* vartype */
! values[4] = config_type_names[conf->vartype];
/* source */
! values[5] = GucSource_Names[conf->source];
/* now get the type specifc attributes */
switch (conf->vartype)
***
*** 3483,3492
case PGC_BOOL:
{
/* min_val */
! values[5] = NULL;
