Thread: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
From
Joe Conway
Date:
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.sql 29 Nov 2003 22:39:40 -0000 1.3
--- src/backend/catalog/system_views.sql 30 Nov 2003 04:58:51 -0000
***************
*** 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.c 29 Nov 2003 19:52:03 -0000 1.172
--- src/backend/utils/misc/guc.c 30 Nov 2003 04:58:52 -0000
***************
*** 156,161 ****
--- 156,162 ----
static char *session_authorization_string;
static char *timezone_string;
static char *XactIsoLevel_string;
+ static int func_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;
/* max_val */
! values[6] = NULL;
}
break;
--- 3497,3506 ----
case PGC_BOOL:
{
/* min_val */
! values[6] = NULL;
/* max_val */
! values[7] = NULL;
}
break;
***************
*** 3496,3506 ****
/* min_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->min);
! values[5] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->max);
! values[6] = pstrdup(buffer);
}
break;
--- 3510,3520 ----
/* min_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->min);
! values[6] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->max);
! values[7] = pstrdup(buffer);
}
break;
***************
*** 3510,3530 ****
/* min_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->min);
! values[5] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->max);
! values[6] = pstrdup(buffer);
}
break;
case PGC_STRING:
{
/* min_val */
! values[5] = NULL;
/* max_val */
! values[6] = NULL;
}
break;
--- 3524,3544 ----
/* min_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->min);
! values[6] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->max);
! values[7] = pstrdup(buffer);
}
break;
case PGC_STRING:
{
/* min_val */
! values[6] = NULL;
/* max_val */
! values[7] = NULL;
}
break;
***************
*** 3536,3545 ****
*/
/* min_val */
! values[5] = NULL;
/* max_val */
! values[6] = NULL;
}
break;
}
--- 3550,3559 ----
*/
/* min_val */
! values[6] = NULL;
/* max_val */
! values[7] = NULL;
}
break;
}
***************
*** 3582,3588 ****
* show_all_settings - equiv to SHOW ALL command but implemented as
* a Table Function.
*/
! #define NUM_PG_SETTINGS_ATTS 7
Datum
show_all_settings(PG_FUNCTION_ARGS)
--- 3596,3602 ----
* show_all_settings - equiv to SHOW ALL command but implemented as
* a Table Function.
*/
! #define NUM_PG_SETTINGS_ATTS 8
Datum
show_all_settings(PG_FUNCTION_ARGS)
***************
*** 3616,3630 ****
TEXTOID, -1, 0, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 3, "context",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 4, "vartype",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 5, "source",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 6, "min_val",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 7, "max_val",
TEXTOID, -1, 0, false);
/* allocate a slot for a tuple with this tupdesc */
--- 3630,3646 ----
TEXTOID, -1, 0, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 3, "short_desc",
! TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 4, "context",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 5, "vartype",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 6, "source",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 7, "min_val",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 8, "max_val",
TEXTOID, -1, 0, false);
/* allocate a slot for a tuple with this tupdesc */
Index: src/test/regress/expected/rules.out
===================================================================
RCS file: /cvsroot/pgsql-server/src/test/regress/expected/rules.out,v
retrieving revision 1.82
diff -c -r1.82 rules.out
*** src/test/regress/expected/rules.out 21 Nov 2003 22:32:49 -0000 1.82
--- src/test/regress/expected/rules.out 30 Nov 2003 04:58:53 -0000
***************
*** 1278,1284 ****
pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname,
pg_get_indexdef(i.oid)AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON
((i.oid= x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND
(i.relkind= 'i'::"char"));
pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM
pg_lock_status()l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid)
ASdefinition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid =
c.relnamespace)))WHERE (r.rulename <> '_RETURN'::name);
! pg_settings | SELECT a.name, a.setting, a.context, a.vartype, a.source, a.min_val, a.max_val FROM
pg_show_all_settings()a(name text, setting text, context text, vartype text, source text, min_val text, max_val text);
pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid,
pg_stat_get_backend_userid(s.backendid)AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS
current_query,pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT
pg_stat_get_backend_idset()AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND
(pg_stat_get_backend_userid(s.backendid)= u.usesysid));
pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname
ASindexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read,
pg_stat_get_tuples_fetched(i.oid)AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN
pg_classi ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char");
pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS
seq_scan,pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan,
sum(pg_stat_get_tuples_fetched(i.indexrelid))AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins,
pg_stat_get_tuples_updated(c.oid)AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT
JOINpg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char")GROUP BY c.oid, n.nspname, c.relname;
--- 1278,1284 ----
pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname,
pg_get_indexdef(i.oid)AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON
((i.oid= x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND
(i.relkind= 'i'::"char"));
pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM
pg_lock_status()l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid)
ASdefinition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid =
c.relnamespace)))WHERE (r.rulename <> '_RETURN'::name);
! pg_settings | SELECT a.name, a.setting, a.short_desc, a.context, a.vartype, a.source, a.min_val,
a.max_valFROM pg_show_all_settings() a(name text, setting text, short_desc text, context text, vartype text, source
text,min_val text, max_val text);
pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid,
pg_stat_get_backend_userid(s.backendid)AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS
current_query,pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT
pg_stat_get_backend_idset()AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND
(pg_stat_get_backend_userid(s.backendid)= u.usesysid));
pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname
ASindexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read,
pg_stat_get_tuples_fetched(i.oid)AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN
pg_classi ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char");
pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS
seq_scan,pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan,
sum(pg_stat_get_tuples_fetched(i.indexrelid))AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins,
pg_stat_get_tuples_updated(c.oid)AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT
JOINpg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char")GROUP BY c.oid, n.nspname, c.relname;
Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
From
Tom Lane
Date:
Joe Conway <mail@joeconway.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
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 peter_e@gmx.net
Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.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
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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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.sql 29 Nov 2003 22:39:40 -0000 1.3
--- src/backend/catalog/system_views.sql 1 Dec 2003 05:49:21 -0000
***************
*** 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.c 1 Dec 2003 03:55:21 -0000 1.173
--- src/backend/utils/misc/guc.c 1 Dec 2003 05:49:23 -0000
***************
*** 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 int func_max_args;
! static int index_max_keys;
! static int name_data_len;
! static int block_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, NULL
},
+ {
+ {"integer_datetimes", PGC_INTERNAL, COMPILE_OPTIONS,
+ gettext_noop("Datetimes are integer based"),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ },
+ &integer_datetimes,
+ #ifdef HAVE_INT64_TIMESTAMP
+ true, NULL, NULL
+ #else
+ false, NULL, NULL
+ #endif
+ },
+
/* End-of-list marker */
{
{NULL, 0, 0, NULL, NULL}, NULL, false, NULL, NULL
***************
*** 1228,1233 ****
--- 1248,1293 ----
100, 1, 1000, NULL, NULL
},
+ {
+ {"func_max_args", PGC_INTERNAL, COMPILE_OPTIONS,
+ gettext_noop("Shows the maximum number of function arguments"),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ },
+ &func_max_args,
+ FUNC_MAX_ARGS, FUNC_MAX_ARGS, FUNC_MAX_ARGS, NULL, NULL
+ },
+
+ {
+ {"index_max_keys", PGC_INTERNAL, COMPILE_OPTIONS,
+ gettext_noop("Shows the maximum number of index keys"),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ },
+ &index_max_keys,
+ INDEX_MAX_KEYS, INDEX_MAX_KEYS, INDEX_MAX_KEYS, NULL, NULL
+ },
+
+ {
+ {"name_data_len", PGC_INTERNAL, COMPILE_OPTIONS,
+ gettext_noop("Shows the maximum identifier length"),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ },
+ &name_data_len,
+ NAMEDATALEN - 1, NAMEDATALEN - 1, NAMEDATALEN - 1, NULL, NULL
+ },
+
+ {
+ {"block_size", PGC_INTERNAL, COMPILE_OPTIONS,
+ gettext_noop("Shows size of a disk block"),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ },
+ &block_size,
+ BLCKSZ, BLCKSZ, BLCKSZ, NULL, NULL
+ },
+
/* End-of-list marker */
{
{NULL, 0, 0, NULL, NULL}, NULL, 0, 0, 0, NULL, NULL
***************
*** 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)
--- 3528,3550 ----
/* setting : use _ShowOption in order to avoid duplicating the logic */
values[1] = _ShowOption(conf);
+ /* group */
+ values[2] = config_group_names[conf->group];
+
+ /* short_desc */
+ values[3] = conf->short_desc;
+
+ /* extra_desc */
+ values[4] = conf->long_desc;
+
/* context */
! values[5] = GucContext_Names[conf->context];
/* vartype */
! values[6] = config_type_names[conf->vartype];
/* source */
! values[7] = GucSource_Names[conf->source];
/* now get the type specifc attributes */
switch (conf->vartype)
***************
*** 3483,3492 ****
case PGC_BOOL:
{
/* min_val */
! values[5] = NULL;
/* max_val */
! values[6] = NULL;
}
break;
--- 3552,3561 ----
case PGC_BOOL:
{
/* min_val */
! values[8] = NULL;
/* max_val */
! values[9] = NULL;
}
break;
***************
*** 3496,3506 ****
/* min_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->min);
! values[5] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->max);
! values[6] = pstrdup(buffer);
}
break;
--- 3565,3575 ----
/* min_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->min);
! values[8] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%d", lconf->max);
! values[9] = pstrdup(buffer);
}
break;
***************
*** 3510,3530 ****
/* min_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->min);
! values[5] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->max);
! values[6] = pstrdup(buffer);
}
break;
case PGC_STRING:
{
/* min_val */
! values[5] = NULL;
/* max_val */
! values[6] = NULL;
}
break;
--- 3579,3599 ----
/* min_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->min);
! values[8] = pstrdup(buffer);
/* max_val */
snprintf(buffer, sizeof(buffer), "%g", lconf->max);
! values[9] = pstrdup(buffer);
}
break;
case PGC_STRING:
{
/* min_val */
! values[8] = NULL;
/* max_val */
! values[9] = NULL;
}
break;
***************
*** 3536,3545 ****
*/
/* min_val */
! values[5] = NULL;
/* max_val */
! values[6] = NULL;
}
break;
}
--- 3605,3614 ----
*/
/* min_val */
! values[8] = NULL;
/* max_val */
! values[9] = NULL;
}
break;
}
***************
*** 3582,3588 ****
* show_all_settings - equiv to SHOW ALL command but implemented as
* a Table Function.
*/
! #define NUM_PG_SETTINGS_ATTS 7
Datum
show_all_settings(PG_FUNCTION_ARGS)
--- 3651,3657 ----
* show_all_settings - equiv to SHOW ALL command but implemented as
* a Table Function.
*/
! #define NUM_PG_SETTINGS_ATTS 10
Datum
show_all_settings(PG_FUNCTION_ARGS)
***************
*** 3616,3630 ****
TEXTOID, -1, 0, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 3, "context",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 4, "vartype",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 5, "source",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 6, "min_val",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 7, "max_val",
TEXTOID, -1, 0, false);
/* allocate a slot for a tuple with this tupdesc */
--- 3685,3705 ----
TEXTOID, -1, 0, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 3, "category",
! TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 4, "short_desc",
! TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 5, "extra_desc",
! TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 6, "context",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 7, "vartype",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 8, "source",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 9, "min_val",
TEXTOID, -1, 0, false);
! TupleDescInitEntry(tupdesc, (AttrNumber) 10, "max_val",
TEXTOID, -1, 0, false);
/* allocate a slot for a tuple with this tupdesc */
Index: src/include/utils/guc_tables.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/utils/guc_tables.h,v
retrieving revision 1.7
diff -c -r1.7 guc_tables.h
*** src/include/utils/guc_tables.h 29 Nov 2003 22:41:15 -0000 1.7
--- src/include/utils/guc_tables.h 1 Dec 2003 05:49:23 -0000
***************
*** 50,56 ****
COMPAT_OPTIONS,
COMPAT_OPTIONS_PREVIOUS,
COMPAT_OPTIONS_CLIENT,
! DEVELOPER_OPTIONS
};
/*
--- 50,57 ----
COMPAT_OPTIONS,
COMPAT_OPTIONS_PREVIOUS,
COMPAT_OPTIONS_CLIENT,
! DEVELOPER_OPTIONS,
! COMPILE_OPTIONS
};
/*
Index: src/test/regress/expected/rules.out
===================================================================
RCS file: /cvsroot/pgsql-server/src/test/regress/expected/rules.out,v
retrieving revision 1.82
diff -c -r1.82 rules.out
*** src/test/regress/expected/rules.out 21 Nov 2003 22:32:49 -0000 1.82
--- src/test/regress/expected/rules.out 1 Dec 2003 05:49:23 -0000
***************
*** 1278,1284 ****
pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname,
pg_get_indexdef(i.oid)AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON
((i.oid= x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND
(i.relkind= 'i'::"char"));
pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM
pg_lock_status()l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid)
ASdefinition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid =
c.relnamespace)))WHERE (r.rulename <> '_RETURN'::name);
! pg_settings | SELECT a.name, a.setting, a.context, a.vartype, a.source, a.min_val, a.max_val FROM
pg_show_all_settings()a(name text, setting text, context text, vartype text, source text, min_val text, max_val text);
pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid,
pg_stat_get_backend_userid(s.backendid)AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS
current_query,pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT
pg_stat_get_backend_idset()AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND
(pg_stat_get_backend_userid(s.backendid)= u.usesysid));
pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname
ASindexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read,
pg_stat_get_tuples_fetched(i.oid)AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN
pg_classi ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char");
pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS
seq_scan,pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan,
sum(pg_stat_get_tuples_fetched(i.indexrelid))AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins,
pg_stat_get_tuples_updated(c.oid)AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT
JOINpg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char")GROUP BY c.oid, n.nspname, c.relname;
--- 1278,1284 ----
pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname,
pg_get_indexdef(i.oid)AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON
((i.oid= x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND
(i.relkind= 'i'::"char"));
pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM
pg_lock_status()l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid)
ASdefinition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid =
c.relnamespace)))WHERE (r.rulename <> '_RETURN'::name);
! pg_settings | SELECT a.name, a.setting, a.category, a.short_desc, a.extra_desc, a.context, a.vartype,
a.source,a.min_val, a.max_val FROM pg_show_all_settings() a(name text, setting text, category text, short_desc text,
extra_desctext, context text, vartype text, source text, min_val text, max_val text);
pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid,
pg_stat_get_backend_userid(s.backendid)AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS
current_query,pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT
pg_stat_get_backend_idset()AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND
(pg_stat_get_backend_userid(s.backendid)= u.usesysid));
pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname
ASindexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read,
pg_stat_get_tuples_fetched(i.oid)AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN
pg_classi ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char");
pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS
seq_scan,pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan,
sum(pg_stat_get_tuples_fetched(i.indexrelid))AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins,
pg_stat_get_tuples_updated(c.oid)AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT
JOINpg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind =
'r'::"char")GROUP BY c.oid, n.nspname, c.relname;
Joe Conway <mail@joeconway.com> 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
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
Joe Conway <mail@joeconway.com> 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
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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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
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 peter_e@gmx.net
Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> 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
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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
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
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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
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
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 peter_e@gmx.net
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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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