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
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
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
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 |
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
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:
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
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
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
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,
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
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
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
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 ...
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 ---
15 matches
Mail list logo
