[COMMITTERS] pgsql: Fix incorrect varlevelsup in security_barrier_replace_vars().

Fix incorrect varlevelsup in security_barrier_replace_vars(). When converting an RTE with securityQuals into a security barrier subquery RTE, ensure that the Vars in the new subquery's targetlist all have varlevelsup = 0 so that they correctly refer to the underlying base relation being wrapped.

[COMMITTERS] pgsql: Fix incorrect varlevelsup in security_barrier_replace_vars().

Fix incorrect varlevelsup in security_barrier_replace_vars(). When converting an RTE with securityQuals into a security barrier subquery RTE, ensure that the Vars in the new subquery's targetlist all have varlevelsup = 0 so that they correctly refer to the underlying base relation being wrapped.

[COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

Add pg_size_bytes() to parse human-readable size strings. This will parse strings in the format produced by pg_size_pretty() and return sizes in bytes. This allows queries to be written with clauses like "pg_total_relation_size(oid) > pg_size_bytes('10 GB')". Author: Pavel Stehule with various

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

On 20 February 2016 at 10:12, Michael Paquier wrote: > Happy first commit. Arg. Not so much. Looks like I broke something -- looking into it now :-( Regards, Dean -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

On 20 February 2016 at 10:33, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sat, Feb 20, 2016 at 7:17 PM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> On 20 February 2016 at 10:12, Michael Paquier <michael.paqu...@gmail.com> >> wrote: >&

[COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

Fix pg_size_bytes() to be more portable. Commit 53874c5228fe16589a4d01b3e1fab3678e0fd8e3 broke various 32-bit buildfarm machines because it incorrectly used an 'L' suffix for what needed to be a 64-bit literal. Thanks to Michael Paquier for helping to diagnose this. Branch -- master Details

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

On 20 February 2016 at 14:54, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> Fix pg_size_bytes() to be more portable. >> Commit 53874c5228fe16589a4d01b3e1fab3678e0fd8e3 broke various 32-bit >> buildfarm machines because

[COMMITTERS] pgsql: Further fixing to make pg_size_bytes() portable.

Further fixing to make pg_size_bytes() portable. Not all compilers support "long long" and the "LL" integer literal suffix, so use a cast to int64 instead. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/740d71842b8e0e798c80f4f841227b6de81b5f43 Modified Files

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

On 20 February 2016 at 16:32, Tom Lane wrote: > After further thought about the portability implications of this --- > > 1. We probably gave up support for long-long-less compilers when we agreed > to start requiring a working int64 type. On a 32-bit machine that's > highly

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

On 20 February 2016 at 17:24, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > It looks to me as though it doesn't need long long anyway, since the > rotation it's doing can be done just as easily with ints, for example: Oh, scratch that -- I was assuming int would be 32-bit, wh

[COMMITTERS] pgsql: Improve estimate of distinct values in estimate_num_groups().

Dilger, Alexander Korotkov, Dean Rasheed and Tom Lane Discussion: http://www.postgresql.org/message-id/flat/56cd0381.5060...@2ndquadrant.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/84f9a35e398f863c62440d3f82fc57b4fedc5d08 Modified Files -- src

[COMMITTERS] pgsql: Fix corner-case loss of precision in numeric pow() calculation

the overall overflow threshold of pow() is unchanged and consistent for all inputs with non-integer exponents. Author: Dean Rasheed Reviewed-by: Tom Lane Discussion: http://www.postgresql.org/message-id/CAEZATCUj3U-cQj0jjoia=qgs0sje3auroxh8swvnkvzwuqe...@mail.gmail.com See-also: http://www.postgresql.org

[COMMITTERS] pgsql: Move and rename fmtReloptionsArray().

accurate description of what it does. Author: Dean Rasheed Reviewed-by: Peter Eisentraut Discussion: http://www.postgresql.org/message-id/CAEZATCWZjCgKRyM-agE0p8ax15j9uyQoF=qew7d2xb6cf76...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff

[COMMITTERS] pgsql: Fix psql's \ev and \sv commands so that they handle view relopti

by pg_get_viewdef() and so need special handling. Author: Dean Rasheed Reviewed-by: Peter Eisentraut Discussion: http://www.postgresql.org/message-id/CAEZATCWZjCgKRyM-agE0p8ax15j9uyQoF=qew7d2xb6cf76...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff

[COMMITTERS] pgsql: Fix order of operations in CREATE OR REPLACE VIEW.

Fix order of operations in CREATE OR REPLACE VIEW. When CREATE OR REPLACE VIEW acts on an existing view, don't update the view options until after the view query has been updated. This is necessary in the case where CREATE OR REPLACE VIEW is used on an existing view that is not updatable, and

[COMMITTERS] pgsql: Fix order of operations in CREATE OR REPLACE VIEW.

Fix order of operations in CREATE OR REPLACE VIEW. When CREATE OR REPLACE VIEW acts on an existing view, don't update the view options until after the view query has been updated. This is necessary in the case where CREATE OR REPLACE VIEW is used on an existing view that is not updatable, and

[COMMITTERS] pgsql: Fix order of operations in CREATE OR REPLACE VIEW.

Fix order of operations in CREATE OR REPLACE VIEW. When CREATE OR REPLACE VIEW acts on an existing view, don't update the view options until after the view query has been updated. This is necessary in the case where CREATE OR REPLACE VIEW is used on an existing view that is not updatable, and

[COMMITTERS] pgsql: Fix order of operations in CREATE OR REPLACE VIEW.

Fix order of operations in CREATE OR REPLACE VIEW. When CREATE OR REPLACE VIEW acts on an existing view, don't update the view options until after the view query has been updated. This is necessary in the case where CREATE OR REPLACE VIEW is used on an existing view that is not updatable, and

Re: [COMMITTERS] pgsql: Fix base backup rate limiting in presence of slow i/o

On 19 December 2016 at 09:17, Magnus Hagander wrote: > Fix base backup rate limiting in presence of slow i/o > > Branch > -- > REL9_4_STABLE I'm seeing a warning on the 9.4 branch that looks to have been caused by this commit: basebackup.c: In function ‘throttle’:

Re: [COMMITTERS] pgsql: Fix base backup rate limiting in presence of slow i/o

On 21 December 2016 at 20:20, Magnus Hagander <mag...@hagander.net> wrote: > On Wed, Dec 21, 2016 at 6:55 PM, Dean Rasheed <dean.a.rash...@gmail.com> >> basebackup.c: In function ‘throttle’: >> basebackup.c:1284:8: warning: variable ‘wait_result’ set but not used &g

[COMMITTERS] pgsql: Comment fix for partition_rbound_cmp().

Comment fix for partition_rbound_cmp(). This was an oversight in d363d42. Beena Emerson Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4de6216877a32e869fe1cf168c1fe1ffb8c3d576 Modified Files -- src/backend/catalog/partition.c | 2 +- 1 file changed, 1

[COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds. Previously, UNBOUNDED meant no lower bound when used in the FROM list, and no upper bound when used in the TO list, which was OK for single-column range partitioning, but problematic with multiple columns. For example, an

Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 21 July 2017 at 09:24, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds. > Hmm, looks like the buildfarm doesn't like this. It looks like the order of partitions listed by \d+ isn't entirely predictable

[COMMITTERS] pgsql: Simplify the logic checking new range partition bounds.

Simplify the logic checking new range partition bounds. The previous logic, whilst not actually wrong, was overly complex and involved doing two binary searches, where only one was really necessary. This simplifies that logic and improves the comments. One visible change is that if the new

[COMMITTERS] pgsql: Clarify the contract of partition_rbound_cmp().

Clarify the contract of partition_rbound_cmp(). partition_rbound_cmp() is intended to compare range partition bounds in a way such that if all the bound values are equal but one is an upper bound and one is a lower bound, the upper bound is treated as smaller than the lower bound. This particular

[COMMITTERS] pgsql: Prevent table partitions from being turned into views.

Prevent table partitions from being turned into views. A table partition must be a table, not a view, so don't allow a "_RETURN" rule to be added that would convert an existing table partition into a view. Amit Langote Discussion:

[COMMITTERS] pgsql: Teach PL/pgSQL about partitioned tables.

table%ROWTYPE and table.col%TYPE work for partitioned tables. Dean Rasheed, reviewed by Amit Langote. Discussion: https://postgr.es/m/CAEZATCUnNOKN8sLML9jUzxecALWpEXK3a3W7y0PgFR4%2Buhgc%3Dg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

[COMMITTERS] pgsql: Teach relation_is_updatable() about partitioned tables.

. This affects the SQL-callable functions pg_relation_is_updatable() and pg_column_is_updatable(), and the views information_schema.views and information_schema.columns. Dean Rasheed, reviewed by Ashutosh Bapat. Discussion: https://postgr.es/m/CAEZATCXnbiFkMXgF4Ez1pmM2c-tS1z33bSq7OGbw7QQhHov%2B6Q

[COMMITTERS] pgsql: Improve the CREATE POLICY documentation.

Improve the CREATE POLICY documentation. Provide a correct description of how multiple policies are combined, clarify when SELECT permissions are required, mention SELECT FOR UPDATE/SHARE, and do some other more minor tidying up. Reviewed by Stephen Frost Discussion:

[COMMITTERS] pgsql: Improve the CREATE POLICY documentation.

Improve the CREATE POLICY documentation. Provide a correct description of how multiple policies are combined, clarify when SELECT permissions are required, mention SELECT FOR UPDATE/SHARE, and do some other more minor tidying up. Reviewed by Stephen Frost Discussion:

[COMMITTERS] pgsql: Improve the CREATE POLICY documentation.

Improve the CREATE POLICY documentation. Provide a correct description of how multiple policies are combined, clarify when SELECT permissions are required, mention SELECT FOR UPDATE/SHARE, and do some other more minor tidying up. Reviewed by Stephen Frost Discussion:

[COMMITTERS] pgsql: Improve the CREATE POLICY documentation.

Improve the CREATE POLICY documentation. Provide a correct description of how multiple policies are combined, clarify when SELECT permissions are required, mention SELECT FOR UPDATE/SHARE, and do some other more minor tidying up. Reviewed by Stephen Frost Discussion:

[COMMITTERS] pgsql: Always require SELECT permission for ON CONFLICT DO UPDATE.

Always require SELECT permission for ON CONFLICT DO UPDATE. The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT permission on the columns of the arbiter index, but it failed to check for that in the case of an arbiter specified by constraint name. In addition, for a table with

[COMMITTERS] pgsql: Always require SELECT permission for ON CONFLICT DO UPDATE.

Always require SELECT permission for ON CONFLICT DO UPDATE. The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT permission on the columns of the arbiter index, but it failed to check for that in the case of an arbiter specified by constraint name. In addition, for a table with

[COMMITTERS] pgsql: Always require SELECT permission for ON CONFLICT DO UPDATE.

Always require SELECT permission for ON CONFLICT DO UPDATE. The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT permission on the columns of the arbiter index, but it failed to check for that in the case of an arbiter specified by constraint name. In addition, for a table with

[COMMITTERS] pgsql: Always require SELECT permission for ON CONFLICT DO UPDATE.

Always require SELECT permission for ON CONFLICT DO UPDATE. The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT permission on the columns of the arbiter index, but it failed to check for that in the case of an arbiter specified by constraint name. In addition, for a table with