Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Thu, 17 Jan 2019 at 03:42, David Rowley wrote: > 35. The evaluation order of this macro is wrong. > > #define ITEM_SIZE(ndims) \ > (ndims * (sizeof(uint16) + sizeof(bool)) + 2 * sizeof(double)) > > You'd probably want ITEM_SIZE(10) to return 170, but: > > select (10 * (2 + 1) + 2 * 8); >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

(Removing Adrien from the CC list, because messages to that address keep bouncing) On Sun, 13 Jan 2019 at 00:31, Tomas Vondra wrote: > > On 1/10/19 6:09 PM, Dean Rasheed wrote: > > > > In the previous discussion around UpdateStatisticsForTypeChange(), the > > consensu

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Sun, 13 Jan 2019 at 00:04, Tomas Vondra wrote: > On 1/12/19 8:49 AM, Dean Rasheed wrote: > > A possible refinement would be to say that if there are more than > > stats_target items more common than this mincount threshold, rather than > > excluding the least common o

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Fri, 11 Jan 2019, 21:18 Tomas Vondra > On 1/10/19 4:20 PM, Dean Rasheed wrote: > > ... > > > > So perhaps what we should do for multivariate stats is simply use the > > relative standard error approach (i.e., reuse the patch in [2] with a > > 20% RSE c

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Wed, 26 Dec 2018 at 22:09, Tomas Vondra wrote: > > Attached is an updated version of the patch - rebased and fixing the > warnings reported by Thomas Munro. > Here are a few random review comments based on what I've read so far: On the CREATE STATISTICS doc page, the syntax in the new

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Wed, 9 Jan 2019 at 15:40, Tomas Vondra wrote: > On 1/8/19 3:18 PM, Dean Rasheed wrote: > > So actually, the estimate for a group of values will be either the MCV > > item's frequency (if the MCV item is kept), or (roughly) the MCV > > item's base_frequency (if the

Policy on cross-posting to multiple lists

Has the policy on cross-posting to multiple lists been hardened recently? The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's message on 8 Jan with an initial proposed patch and my response later that day both CC'ed -hackers and seem to have been rejected, and so are missing from

Re: BUG #15446: Crash on ALTER TABLE

On Wed, 9 Jan 2019 at 23:24, Andrew Dunstan wrote: > Here's another attempt. For the rewrite case it kept the logic of the > previous patch to clear all the missing attributes, but if we're not > rewriting we reconstruct the missing value according to the new type > settings. > Looks good to me.

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Mon, 7 Jan 2019 at 00:45, Tomas Vondra wrote: > > FWIW the main unsolved issue (at least on the MCV part) is how it > decides which items to keep in the list. > > As explained in [1], in the multivariate case we can't simply look at > the group frequency and compare it to the average frequency

Re: Statement-level Triggers For Uniqueness Checks

On Tue, 25 Dec 2018 at 08:04, Dean Rasheed wrote: > Take a look at this code in AfterTriggerSaveEvent(): > Note that the intention behind that code is that in the (fairly common) case where an insert or update operation is known to not lead to any potential PK/UNIQUE index viol

Re: Statement-level Triggers For Uniqueness Checks

On Mon, 24 Dec 2018 at 23:57, Corey Huinker wrote: > > So I took a first pass at this, and I got stuck. > > [snip] > > Any idea where I went wrong? Take a look at this code in AfterTriggerSaveEvent(): /* * If the trigger is a deferred unique constraint check trigger, only

Re: COPY FROM WHEN condition

On Sat, 24 Nov 2018 at 02:09, Tomas Vondra wrote: > On 11/23/18 12:14 PM, Surafel Temesgen wrote: > > On Sun, Nov 11, 2018 at 11:59 PM Tomas Vondra > > mailto:tomas.von...@2ndquadrant.com>> wrote: > > So, what about using FILTER here? We already use it for aggregates when > > filtering

Re: Proposed HTML Documentation Styles

On Thu, 11 Oct 2018 at 06:49, Dean Rasheed wrote: > For example, attached are screenshots taken from my Android tablet For the record, that was a Samsung Galaxy Tab S2 8.0, with a screen resolution of 2048x1536 and a device pixel ratio of 2.0, I think. So the logical resolution is 1024x

Re: BUG #15307: Low numerical precision of (Co-) Variance

On Wed, 3 Oct 2018 at 15:58, Madeleine Thompson wrote: > This diff looks good to me. Also, it applies cleanly against > abd9ca377d669a6e0560e854d7e987438d0e612e and passes `make > check-world`. > > I agree that this is not suitable for a patch release. > Pushed to master. Thanks for the review.

pgsql: Improve the accuracy of floating point statistical aggregates.

Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating

Re: Proposed HTML Documentation Styles

On Thu, 4 Oct 2018 at 16:50, Jonathan S. Katz wrote: > As part of the effort to modernize the look and feel of PostgreSQL.org > and associated web projects, Sarah & I have worked on applying the new > styles to the documentation. > > We are looking for feedback in the following areas: > > -

Re: BUG #15307: Low numerical precision of (Co-) Variance

On Thu, 27 Sep 2018 at 14:22, Dean Rasheed wrote: > I'll post an updated patch in a while. > I finally got round to looking at this again. Here is an update, based on the review comments. The next question is whether or not to back-patch this. Although this was reported as a bug, my incli

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

On Mon, 1 Oct 2018 at 21:45, Carl Sverre wrote: > Dean, > Thank you for the pointer towards visibility/volatility. I think that > completely explains the effect that I am seeing in my repro. I experimented > with using a VOLATILE function for the SELECT RLS using statement and while > it

Re: BUG #15307: Low numerical precision of (Co-) Variance

On 27 September 2018 at 06:12, Madeleine Thompson wrote: > This is my first PostgreSQL review. Hopefully I'm getting it right. I > independently ran into the bug in question and found that the author had > already written a patch. I'm happy the author wrote this. > Thanks for the review. And

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 3 September 2018 at 00:17, Tomas Vondra wrote: > Hi, > > Attached is an updated version of the patch series, adopting a couple of > improvements - both for MCV lists and histograms. > > > MCV > --- > > For the MCV list part, I've adopted the approach proposed by Dean, using > base selectivity

Re: [HACKERS] proposal: schema variables

AFAICS this patch does nothing to consider parallel safety -- that is, as things stand, a variable is allowed in a query that may be parallelised, but its value is not copied to workers, leading to incorrect results. For example: create table foo(a int); insert into foo select * from

Re: Will there ever be support for Row Level Security on Materialized Views?

On 28 August 2018 at 01:49, Alvaro Herrera wrote: > On 2018-Aug-27, Ken Tanzer wrote: >>- In the scheme of things, is it a lot of work or not so much? > > Probably not much. > Yeah, it doesn't seem like it would be particularly difficult, but it would probably still be a reasonable amount of

Re: pgsql: Provide separate header file for built-in float types

On 29 July 2018 at 02:43, Tomas Vondra wrote: > Provide separate header file for built-in float types It looks like this commit broke float8_accum() and float4_accum() when not invoked as aggregates (transdatums is no longer being populated). Possibly it would be worth having regression tests

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

On 26 July 2018 at 07:12, Ashutosh Bapat wrote: > In the patch clauselist_selectivity() gets called repeatedly for every > new qual added to the clause list. Instead, if we try to combine the > cost/row estimation with order_qual_clauses() or > clauselist_selectivity(), we might be able to what

Re: Order of execution for permissive RLS policies

On 24 July 2018 at 15:25, Simon Brent wrote: > I've been using postgres for a while now, and have just started looking in > to row level security. I have found something that I think is a bit strange, > and wanted to know if anyone knows how/why it is the case. > > I have a table with multiple

pgsql: Guard against rare RAND_bytes() failures in pg_strong_random().

it using RAND_poll(). Back-patch to v10, where pg_strong_random() was introduced. Dean Rasheed and Michael Paquier. Discussion: https://postgr.es/m/CAEZATCXMtxbzSAvyKKk5uCRf9pNt4UV%2BF_5v%3DgLfJUuPxU4Ytg%40mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg

pgsql: Guard against rare RAND_bytes() failures in pg_strong_random().

it using RAND_poll(). Back-patch to v10, where pg_strong_random() was introduced. Dean Rasheed and Michael Paquier. Discussion: https://postgr.es/m/CAEZATCXMtxbzSAvyKKk5uCRf9pNt4UV%2BF_5v%3DgLfJUuPxU4Ytg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg

pgsql: Guard against rare RAND_bytes() failures in pg_strong_random().

it using RAND_poll(). Back-patch to v10, where pg_strong_random() was introduced. Dean Rasheed and Michael Paquier. Discussion: https://postgr.es/m/CAEZATCXMtxbzSAvyKKk5uCRf9pNt4UV%2BF_5v%3DgLfJUuPxU4Ytg%40mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg

Re: PG 10: could not generate random cancel key

On 18 July 2018 at 14:01, Michael Paquier wrote: > Thanks for the updated version. This looks safer to me. It is possible > to simplify the code by removing the external RAND_status() call and > check for RAND_status() first in the loop as per the attached. OK, thanks. Barring any further

Re: PG 10: could not generate random cancel key

On 18 July 2018 at 03:17, Michael Paquier wrote: >> [1] https://wiki.openssl.org/index.php/Random_Numbers > > This quote from the wiki is scary so that's not quite clean either for > Windows: > "Be careful when deferring to RAND_poll on some Unix systems because it > does not seed the generator.

Re: PG 10: could not generate random cancel key

On 17 July 2018 at 14:04, Michael Paquier wrote: > On Tue, Jul 17, 2018 at 01:33:11PM +0100, Dean Rasheed wrote: >> Looking for precedents elsewhere, I found [2] which does exactly that, >> although I'm slightly dubious about the need for the for-loop there. I >> also foun

PG 10: could not generate random cancel key

Last week I upgraded 15 servers from various pre-10 versions to 10.4. At first everything looked OK, but then (around 4 days later) one of them failed with this in the logs: 2018-07-14 01:53:35.840 BST LOG: could not generate random cancel key 2018-07-14 01:53:37.233 BST LOG: could not

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 16 July 2018 at 21:55, Tomas Vondra wrote: > > > On 07/16/2018 02:54 PM, Dean Rasheed wrote: >> On 16 July 2018 at 13:23, Tomas Vondra wrote: >>>>> The top-level clauses allow us to make such deductions, with deeper >>>>> clauses it's much

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 16 July 2018 at 13:23, Tomas Vondra wrote: >>> The top-level clauses allow us to make such deductions, with deeper >>> clauses it's much more difficult (perhaps impossible). Because for >>> example with (a=1 AND b=1) there can be just a single match, so if we >>> find it in MCV we're done.

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 15 July 2018 at 14:29, Tomas Vondra wrote: > It's quite unclear to me how this algorithm could reliably end up with > hist_sel=0 (in cases where we already don't end up with that). I mean, > if a bucket matches the conditions, then the only way to eliminate is by > deducing that MCV already

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 13 July 2018 at 18:27, Tomas Vondra wrote: > I'm not so sure. The issue is that a lot of the MCV deductions depends > on whether we can answer questions like "Is there a single match?" or > "If we got a match in MCV, do we need to look at the non-MCV part?" This > is not very different from

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 24 June 2018 at 20:45, Tomas Vondra wrote: > Attached is a rebased version of this patch series, mostly just fixing > the breakage caused by reworked format of initial catalog data. > > Aside from that, the MCV building now adopts the logic introduced by > commit b5db1d93d2 for single-column

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

On 16 May 2018 at 14:44, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> In the case 1 ^ NaN = 1, what should the result scale be? > > The result is exact, so I don't see a reason to be worried about its > scale. Messing wit

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

On 15 May 2018 at 22:55, Tom Lane wrote: > David Rowley writes: >> On 16 May 2018 at 02:01, Tom Lane wrote: >>> I'm not particularly fussed about getting credit for that. However, >>> looking again at how that patch series

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 7 April 2018 at 15:12, Bruce Momjian wrote: > Uh, where are we on this patch? It isn't going to make it into PG 11? > Feature development for this has been going on for years. Unfortunately, I think there's no way that this will be ready for PG11. So far, I have only read

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 28 March 2018 at 15:50, Tomas Vondra wrote: > After thinking about this a bit more, I'm not sure if updating the info > based on recursive calls makes sense. The fullmatch flag was supposed to > answer a simple question - can there be just a single matching item?

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 28 March 2018 at 01:34, Tomas Vondra wrote: > Attached is a patch fixing this. In the end I've decided to keep both > branches - one handling boolean Vars and one for NOT clauses. I think > you're right we can only see (NOT var) cases, but I'm not sure about that.

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 27 March 2018 at 14:58, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 27 March 2018 at 01:36, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: >> 4) handling of NOT clauses in MCV lists (and in histograms) >> >> The query you posted does not fail

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 27 March 2018 at 01:36, Tomas Vondra wrote: > BTW I think there's a bug in handling the fullmatch flag - it should not > be passed to AND/OR subclauses the way it is, because then > > WHERE a=1 OR (a=2 AND b=2) > > will probably set it to 'true' because of

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 27 March 2018 at 01:36, Tomas Vondra wrote: > 4) handling of NOT clauses in MCV lists (and in histograms) > > The query you posted does not fail anymore... > Ah, it turns out the previous query wasn't actually failing for the reason I thought it was -- it was

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 26 March 2018 at 20:17, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 03/26/2018 09:01 PM, Dean Rasheed wrote: >> Also, just above that, in statext_clauselist_selectivity(), it >> computes the list stat_clauses, then doesn't appear to use it >> anywhere. I

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 18 March 2018 at 23:57, Tomas Vondra wrote: > Attached is an updated version of the patch series, addressing issues > pointed out by Alvaro. I've just been reading the new code in statext_clauselist_selectivity() and mcv_clauselist_selectivity(), and I'm having a

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 26 March 2018 at 14:08, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 03/26/2018 12:31 PM, Dean Rasheed wrote: >> A wider concern I have is that I think this function is trying to be >> too clever by only resetting selected stats. IMO it should just reset >>

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 18 March 2018 at 23:57, Tomas Vondra wrote: > Attached is an updated version of the patch series, addressing issues > pointed out by Alvaro. I'm just starting to look at this now, and I think I'll post individual comments/questions as I get to them rather than

Re: MCV lists for highly skewed distributions

On 19 March 2018 at 16:59, John Naylor <jcnay...@gmail.com> wrote: > On 3/19/18, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >> As promised, here is a new patch, with comment updates, per John and >> Tomas' suggestions, plus the continuity correction, which seem

pgsql: Improve ANALYZE's strategy for finding MCVs.

Improve ANALYZE's strategy for finding MCVs. Previously, a value was included in the MCV list if its frequency was 25% larger than the estimated average frequency of all nonnull values in the table. For uniform distributions, that can lead to values being included in the MCV list and

Re: MCV lists for highly skewed distributions

On 18 March 2018 at 22:52, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > I'll post something tomorrow, once I've finished wordsmithing the comments. > As promised, here is a new patch, with comment updates, per John and Tomas' suggestions, plus the continuity correction, which

Re: MCV lists for highly skewed distributions

On 18 March 2018 at 12:24, John Naylor wrote: > Over the weekend I tried out a test to measure: > -The size of the MCV list > -The ratio between actual and estimated cardinality of the least > common value in the MCV list. > -The ratio between actual and estimated cardinality

Re: MCV lists for highly skewed distributions

On 17 March 2018 at 18:40, Tomas Vondra wrote: > Currently, analyze_mcv_list only checks if the frequency of the current > item is significantly higher than the non-MCV selectivity. My question > is if it shouldn't also consider if removing the item from MCV would

Re: MCV lists for highly skewed distributions

On 16 March 2018 at 15:26, Tomas Vondra wrote: > Actually, one question - when deciding whether to keep the item in the > MCV list, analyze_mcv_list only compares it's frequency with an average > of the rest. But as we're removing items from the MCV list, the average

Re: MCV lists for highly skewed distributions

On 17 March 2018 at 17:16, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Using the calculator above, you can see that the distribution is > fairly normal-like, but with a noticeable positive skew. The 2-stddev > interval is 0.6 to 9.4, and according to the calculator th

Re: MCV lists for highly skewed distributions

On 13 March 2018 at 08:39, John Naylor wrote: >> Also, this is common enough that in fact that distribution >> can be reasonably approximated by a normal distribution. > > For the archives, because it's typically seen 10 times in the sample, > per the rule of thumb mention

Re: MCV lists for highly skewed distributions

> On 03/11/2018 10:23 AM, Dean Rasheed wrote: >> I'm moving this back to a status of "Needs review" partly because the >> code has changed significantly, but also because I want to do more >> testing, particularly with larger datasets. >> John, Tomas, Thanks

Re: Bogus use of canonicalize_qual

On 10 March 2018 at 20:21, Tom Lane wrote: > I wrote: >> Whilst fooling about with predtest.c, I noticed a rather embarrassing >> error. Consider the following, rather silly, CHECK constraint: >> ... >> So, what to do? We have a few choices, none ideal: > > I'd been assuming

Re: MCV lists for highly skewed distributions

On 6 March 2018 at 08:51, John Naylor <jcnay...@gmail.com> wrote: > On 3/5/18, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >> Attached is an updated patch. > Nice. The results look good. Thanks for the review. > I agree it should be in a separate function. As

Re: MCV lists for highly skewed distributions

On 7 February 2018 at 15:58, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 7 February 2018 at 15:25, Robert Haas <robertmh...@gmail.com> wrote: >> Do you plan to press forward with this, then, or what's >> the next step? > > I plan to do more testing TL;DR:

Re: MCV lists for highly skewed distributions

On 1 March 2018 at 21:01, Andres Freund wrote: > This sounds like the patch's status of "waiting on author" isn't right, > and it should more be ready for committer? > Yes, I'll take a look at it this weekend. Regards, Dean

Re: MCV lists for highly skewed distributions

On 7 February 2018 at 15:25, Robert Haas wrote: > Do you plan to press forward with this, then, or what's > the next step? > Yes, I think the results are pretty good so far, especially for the more non-uniform distributions. AFAICS it solves the 2 original complaints, and

Re: MCV lists for highly skewed distributions

On 4 February 2018 at 12:18, John Naylor wrote: > I did the same basic eyeball testing I did on earlier patches, and > this is the best implementation so far. I've attached some typical > pg_stats contents for HEAD and this patch. More rigorous testing, > including of planner

Re: MCV lists for highly skewed distributions

On 1 February 2018 at 17:49, Robert Haas wrote: > One point which I want to emphasize is that the length of the MCV list > bounds the estimated frequency of non-MCVs in two ways: no non-MCV is > ever thought to be more frequent than the least-common MCVs, and > however many

Re: MCV lists for highly skewed distributions

On 1 February 2018 at 13:16, Simon Riggs wrote: > On 25 January 2018 at 22:19, Tom Lane wrote: >> In any case, since it looks like the next step is for someone to come >> up with a new proposal, I'm going to set this to Waiting on Author. > > Dean and

Re: WINDOW RANGE patch versus leakproofness

On 31 January 2018 at 21:51, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> On 30 January 2018 at 16:42, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> So I'm thinking that (a) we d

Re: WINDOW RANGE patch versus leakproofness

On 30 January 2018 at 16:42, Tom Lane wrote: > So I'm thinking that (a) we do not need to check for leaky functions used > in window support, and (b) therefore there's no need to avoid leaky > behavior in in_range support functions. Objections? > Yes, I concur. Since window

Re: stricter MCV tests for uniform distributions (was Re: MCV lists for highly skewed distributions)

On 22 January 2018 at 08:07, John Naylor <jcnay...@gmail.com> wrote: > On 1/21/18, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >> It occurs to me that maybe a better test to exclude a value from the >> MCV list would be to demand that its relative standard error not

Re: MCV lists for highly skewed distributions

lve > right now. The logic suggested by Dean Rasheed in [1] always produces > no MCVs for a perfectly uniform distribution (which is good), but very > often also for other distributions, which is not good. My efforts to > tweak that didn't work, so I didn't get as far as adapting it for t

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On 27 November 2017 at 16:35, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Dean Rasheed <dean.a.rash...@gmail.com> writes: >>> A separate point -- it might be marginally more efficient to have the >>> work of rewriteTargetListUD() done after expand

pgsql: RLS comment fixes.

RLS comment fixes. The comments in get_policies_for_relation() say that CREATE POLICY does not support defining restrictive policies. This is no longer true, starting from PG10. Branch -- master Details ---

pgsql: RLS comment fixes.

RLS comment fixes. The comments in get_policies_for_relation() say that CREATE POLICY does not support defining restrictive policies. This is no longer true, starting from PG10. Branch -- REL_10_STABLE Details ---

[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

[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:

Re: [HACKERS] Row Level Security Documentation

On 26 September 2017 at 00:42, Stephen Frost <sfr...@snowman.net> wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> Attached is a proposed patch... > > I've taken a look through this and generally agree with it. Thanks for looking at this. > the bits

Re: [HACKERS] Row Level Security Documentation

On 5 August 2017 at 10:03, Fabien COELHO wrote: > Patch applies cleanly, make html ok, new table looks good to me. > So I started looking at this patch, but before even considering the new table proposed, I think there are multiple issues that need to be resolved with the

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

On 14 September 2017 at 03:49, Noah Misch wrote: > On Wed, Sep 13, 2017 at 12:06:40PM -0400, Robert Haas wrote: >> OK, thanks. I still don't really like allowing this, but I can see >> that compatibility with other systems has some value here, and if >> nobody else is

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

On 13 September 2017 at 14:51, Robert Haas wrote: > Coincidentally, I wrote a patch for this too, but mine goes back to > rejecting MINVALUE or MAXVALUE followed by anything else. > LGTM, if we decide to go this way. One minor review comment -- you missed an example code

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

On 13 September 2017 at 10:05, Amit Langote wrote: > Coincidentally, I just wrote the patch for canonicalizing stored values, > instead of erroring out. Please see attached if that's what you were > thinking too. > Looks reasonable to me, if we decide to go this

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

On 13 September 2017 at 14:53, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Sep 13, 2017 at 4:51 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> A drawback to doing this is that we lose compatibility with syntaxes >> supported by other databases

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

Robert Haas writes: > On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera > wrote: >> Did anything happen on this, or did we just forget it completely? > > I forgot it. :-( > > I really think we should fix this. Ah, sorry. This was for me to follow

Re: [HACKERS] dubious error message from partition.c

On 9 August 2017 at 13:03, Robert Haas wrote: > On Tue, Aug 8, 2017 at 11:34 PM, Tom Lane wrote: >> A small suggestion is that it'd be better to write it like "Specified >> upper bound \"%s\" precedes lower bound \"%s\"." I think "succeeds" has >> more

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

On 8 August 2017 at 19:22, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> Also drop the constraint prohibiting finite values after an unbounded >> column, and just document the fact

Re: [HACKERS] Minor comment update in partition.c

On 31 July 2017 at 12:53, Beena Emerson wrote: > The commit d363d42bb9a4399a0207bd3b371c966e22e06bd3 changed > RangeDatumContent *content to PartitionRangeDatumKind *kind but a > comment on function partition_rbound_cmp was left unedited and it > still mentions content1

[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

Re: [HACKERS] Multi column range partition table

On 17 July 2017 at 17:37, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 17 July 2017 at 16:34, Robert Haas <robertmh...@gmail.com> wrote: >> Do you want to own this open item, then? >> > OK. > > I need to give the patch another read-through, and

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: 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: [HACKERS] Multi column range partition table

On 17 July 2017 at 16:34, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can >> also be done using using MINVALUE/MA

Re: [HACKERS] Multi column range partition table

On 14 July 2017 at 06:12, Robert Haas wrote: > I agree that it's a big problem that (10, UNBOUNDED) > interpreted as a maximum value means first_column <= 10 and when > interpreted as a minimum value means first_column >= 10, because those > things aren't opposites of each

Re: [HACKERS] Multi column range partition table

On 12 July 2017 at 10:46, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Jul 12, 2017 at 12:54 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> On 11 July 2017 at 13:29, Ashutosh Bapat >>> The description in this paragraph seems to b

Re: [HACKERS] New partitioning - some feedback

On 12 July 2017 at 23:23, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > I also agree that there probably isn't much need for a list that > *only* includes partitions, but if someone comes up with a convincing > use case, then we could add another 2-letter command for that. >

Re: [HACKERS] New partitioning - some feedback

On 12 July 2017 at 15:58, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2017/07/11 13:34, Alvaro Herrera wrote: >> > However, the "list tables" >> > command \dt should definitely IMO not list partitions. >> >> Do you mean never? Even if a modifier is specified? In

<    3   4   5   6   7   8   9   10   11   12   >