Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 24 September 2015 at 11:33, Gavin Flower wrote: > An example from a book on PostgreSQL server programming that I'm working > through (Note that it is obviously awkward to write with gender pronouns > when gender is irrelevant, note the "he she" in one place and

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 24/09/15 22:41, Geoff Winkless wrote: On 24 September 2015 at 11:33, Gavin Flower >wrote: An example from a book on PostgreSQL server programming that I'm working through (Note that it is obviously awkward to

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

An example from a book on PostgreSQL server programming that I'm working through (Note that it is obviously awkward to write with gender pronouns when gender is irrelevant, note the "he she" in one place and "he/she" in another!): "If the user is a superuser, then he she has permission

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

[COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Lower *_freeze_max_age minimum values. The old minimum values are rather large, making it time consuming to test related behaviour. Additionally the current limits, especially for multixacts, can be problematic in space-constrained systems. 1000 multixacts can contain a lot of members. Since

Re: [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Andres Freund writes: > Lower *_freeze_max_age minimum values. Should this patch not have also touched the per-table limits in reloptions.c? Also, I went looking for documentation about the minimum allowed values, and I found places in create_table.sgml that claim these

[COMMITTERS] pgsql: Make pg_controldata report newest XID with valid commit timestam

Make pg_controldata report newest XID with valid commit timestamp Previously pg_controldata didn't report newestCommitTs and this was an oversight in commit 73c986a. Also this patch changes pg_resetxlog so that it uses the same sentences as pg_controldata does, regarding oldestCommitTs and

[COMMITTERS] pgsql: Make pg_controldata report newest XID with valid commit timestam

Make pg_controldata report newest XID with valid commit timestamp Previously pg_controldata didn't report newestCommitTs and this was an oversight in commit 73c986a. Also this patch changes pg_resetxlog so that it uses the same sentences as pg_controldata does, regarding oldestCommitTs and

Re: [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

On 2015-09-24 10:37:33 -0400, Tom Lane wrote: > Andres Freund writes: > > Lower *_freeze_max_age minimum values. > > Should this patch not have also touched the per-table limits in > reloptions.c? Hm. I guess that'd make sense. It's not really related to the goal of making

[COMMITTERS] pgsql: Don't zero opfuncid when reading nodes.

Don't zero opfuncid when reading nodes. The comments here stated that this was just in case we ever had an ALTER OPERATOR command that could remap an operator to a different function. But those comments have been here for a long time, and no such command has come about. In the absence of such a

[COMMITTERS] pgsql: Improve handling of collations in contrib/postgres_fdw.

Improve handling of collations in contrib/postgres_fdw. If we have a local Var of say varchar type with default collation, and we apply a RelabelType to convert that to text with default collation, we don't want to consider that as creating an FDW_COLLATE_UNSAFE situation. It should be okay to

[COMMITTERS] pgsql: Improve handling of collations in contrib/postgres_fdw.

Improve handling of collations in contrib/postgres_fdw. If we have a local Var of say varchar type with default collation, and we apply a RelabelType to convert that to text with default collation, we don't want to consider that as creating an FDW_COLLATE_UNSAFE situation. It should be okay to

[COMMITTERS] pgsql: Improve handling of collations in contrib/postgres_fdw.

Improve handling of collations in contrib/postgres_fdw. If we have a local Var of say varchar type with default collation, and we apply a RelabelType to convert that to text with default collation, we don't want to consider that as creating an FDW_COLLATE_UNSAFE situation. It should be okay to

[COMMITTERS] pgsql: Improve handling of collations in contrib/postgres_fdw.

Improve handling of collations in contrib/postgres_fdw. If we have a local Var of say varchar type with default collation, and we apply a RelabelType to convert that to text with default collation, we don't want to consider that as creating an FDW_COLLATE_UNSAFE situation. It should be okay to

[COMMITTERS] pgsql: Allow planner to use expression-index stats for function calls i

Allow planner to use expression-index stats for function calls in WHERE. Previously, a function call appearing at the top level of WHERE had a hard-wired selectivity estimate of 0.333, a kludge conveniently dated in the source code itself to July 1992. The expectation at the time was that

[COMMITTERS] pgsql: Allow planner to use expression-index stats for function calls i

Allow planner to use expression-index stats for function calls in WHERE. Previously, a function call appearing at the top level of WHERE had a hard-wired selectivity estimate of 0.333, a kludge conveniently dated in the source code itself to July 1992. The expectation at the time was that

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

Further fix for psql's code for locale-aware formatting of numeric output. On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv().

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could

Re: [COMMITTERS] pgsql: RLS refactoring

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > My vote would be to rename and reposition the field in HEAD and 9.5 > and accept the corresponding initdb. We already forced an initdb > since alpha2, so it's basically free as far as testers are concerned, > and keeping 9.5 in sync with HEAD in

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could

[COMMITTERS] pgsql: Fix psql's code for locale-aware formatting of numeric output.

Fix psql's code for locale-aware formatting of numeric output. This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could