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 (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 (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
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
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 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
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
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 (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:
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
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 true, NULL,
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: 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: 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
[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;
