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

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: [HACKERS] custom function for converting human readable sizes to bytes

On 18 February 2016 at 10:05, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > OK, I'll add a check for that. > Thanks for testing. > Pushed, with a catversion bump. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your sub

[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: [HACKERS] custom function for converting human readable sizes to bytes

On 18 February 2016 at 02:00, Vitaly Burovoy wrote: >> + else >> + have_digits = false; > Does it worth to move it to the declaration and remove that "else" block? > + boolhave_digits = false; OK, that's probably a bit neater. > Is it

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 17 February 2016 at 02:32, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 2/11/16 4:21 AM, Dean Rasheed wrote: >> >> Thinking about this some more though, perhaps*sorting* the columns is >> the wrong way to be thinking about it. Perhaps a better approach would

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 15 February 2016 at 14:08, Daniel Verite <dan...@manitou-mail.org> wrote: > Dean Rasheed wrote: > >> My biggest problem is with the sorting, for all the reasons discussed >> above. There is absolutely no reason for \crosstabview to be >> re-sorting ro

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 17 February 2016 at 00:39, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: >> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >>> Fixing that in parse_memory_unit() would be messy beca

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 16 February 2016 at 05:01, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2016-02-15 10:16 GMT+01:00 Dean Rasheed <dean.a.rash...@gmail.com>: >> Is there any reason not to make >> pg_size_bytes() return numeric? >> > This is a question. I have not a stron

Re: [HACKERS] custom function for converting human readable sizes to bytes

> On 12/02/16 10:19, Dean Rasheed wrote: >> This seems like a reasonable first patch for me as a committer, so >> I'll take it unless anyone else was planning to do so. > So looking at this, it seems that for the most part pg_size_bytes() will parse any output produced

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 12 February 2016 at 06:25, Pavel Stehule wrote: > Thank you for review and other work > This seems like a reasonable first patch for me as a committer, so I'll take it unless anyone else was planning to do so. Regards, Dean -- Sent via pgsql-hackers mailing list

Re: [HACKERS] max_parallel_degree context level

On 11 February 2016 at 13:18, Robert Haas wrote: > On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote: >> As it currently stands, max_parallel_degree is set to a superuser >> context > > I don't have a clue why it's like that. It seems like it should be >

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 11 February 2016 at 08:43, Andres Freund <and...@anarazel.de> wrote: > On 2016-02-09 09:27:04 +0000, Dean Rasheed wrote: >> Looking at this patch, I have mixed feelings about it. On the one hand >> I really like the look of the output, and I can see that the non-fixed &g

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 9 February 2016 at 05:24, Pavel Stehule wrote: > I have not a feeling so we did some with Daniel privately. All work was > public (I checked my mailbox) - but what is unhappy - in more mailing list > threads (not sure how it is possible, because subjects looks same).

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 9 February 2016 at 10:09, Pavel Stehule wrote: > The sorting on client side is necessary - minimally in one direction, > because you cannot to create perfect sorting for both dimensions. > Possibility to order in second dimension is just pretty comfortable - > because

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 9 February 2016 at 11:06, Pavel Stehule wrote: > + respect SQL clauses ordering, allows pretty complex ORDER BY clause That, to me is the key point. SQL already allows very powerful sorting, so psql should not just throw away the query's sort order and replace it

Re: [HACKERS] Multi-tenancy with RLS

On 9 February 2016 at 19:47, Robert Haas wrote: > I think you're dismissing Tom's concerns far too lightly. The > row_security=off mode, which is the default, becomes unusable for > non-superusers under this proposal. That's bad. And if you switch to > the other mode,

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 23 January 2016 at 23:04, Tom Lane wrote: > Noah Misch writes: >> On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote: >>> Either I missed something or there's another issue, because tern/sungazer >>> are *still* failing. This is getting annoying

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 19 January 2016 at 06:32, Michael Paquier wrote: > The first patch looks fine to me, a nitpick: > + /* Be sure to throw an error if the input is infinite --- see dcos */ > s/dcos/docs > No, I meant dcos the function there. I would normally write that as dcos()

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 30 November 2015 at 14:11, Tom Lane wrote: > FWIW, I think that probably the best course of action is to go ahead > and install POSIX-compliant error checking in the existing functions > too. POSIX:2008 is quite clear about this: > > : An application wishing to check for

Re: [HACKERS] Add numeric_trim(numeric)

On 6 January 2016 at 15:21, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Actually I found the implementation a little confusing, partly because > the first comment doesn't really match the line of code that follows > it, and partly because of the complexity of the l

Re: [HACKERS] Add numeric_trim(numeric)

On 7 January 2016 at 00:11, Tom Lane wrote: > A different approach is that I'm not real sure why we want a function > that returns a modified numeric value at all. To the extent I understood > Marko's original use case, it seems like what you'd invariably do with the > result

Re: [HACKERS] Add numeric_trim(numeric)

On 27 December 2015 at 07:11, Pavel Stehule wrote: >> 2015-11-19 3:58 GMT+01:00 Marko Tiikkaja : >>> Here's a patch for the second function suggested in >>> 5643125e.1030...@joh.to. >>> > So I am sending a review of this patch. > I took a quick look at this

Re: [HACKERS] Add numeric_trim(numeric)

On 6 January 2016 at 20:09, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> It seems like a useful function to have, but perhaps it should just be >> called trim() rather than n

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 10 December 2015 at 20:02, Tom Lane wrote: > Robert Haas writes: >> It seems to be a loss of 4 digits in every case I've seen. > > I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth > of rscale in each of these functions so

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 10 December 2015 at 20:02, Tom Lane wrote: >> It seems to be a loss of 4 digits in every case I've seen. > > I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth > of rscale in each of these functions so that the discrepancies tend to > favor more

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 1 December 2015 at 12:59, Michael Paquier wrote: > Dean, are you planning to continue working on this patch? If yes, are > you fine to move it to next CF? It seems that the current consensus is > to split this effort into two patches: Yes, I still plan to work on

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 11 November 2015 at 11:45, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Thanks for testing. I'll post an updated patch sometime soon. > I finally got round to looking at this again, and here is an updated patch. I've reverted the changes to the CHECKFLOATVAL() checks in

Re: [HACKERS] Bug in numeric multiplication

On 24 November 2015 at 16:20, Tom Lane wrote: > After further thought I've pretty well convinced myself that there is > indeed no observable bug, at least as long as you assume that overflow > within the multiplication will behave as stated above. The proof goes > like this:

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On 21 November 2015 at 03:54, Marko Tiikkaja wrote: > Here's v2 of the patch. How's this look? > Here are some initial review comments: * My first thought on reading this patch is that it is somewhat under-commented. For example, I would expect at least a block comment at the top

Re: [HACKERS] Bug in numeric multiplication

On 18 November 2015 at 22:19, Tom Lane wrote: > A bit of progress on this: I've found a test case, namely > > select sqrt(99... > Wow. > Still, this proves that we are onto a real problem. > Agreed. I had a go at turning that example into something using log(base, num)

Re: [HACKERS] Bug in numeric multiplication

On 17 November 2015 at 23:57, Tom Lane wrote: > After thinking some more about what this is doing, it seems to me that > we could avoid changing div[qi + 1] at all here, and instead deal with > leftover dividend digits by shoving them into the floating-point part of > the

Re: [HACKERS] Bug in numeric multiplication

On 17 November 2015 at 14:43, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> I just noticed that div_var_fast() has almost identical code, and so >> in principle it has the same vulnerability, although it obviously only &g

Re: [HACKERS] Bug in numeric multiplication

On 21 September 2015 at 17:14, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 21 September 2015 at 16:09, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> After trying to rework the comment to explain what maxdig really

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 14 November 2015 at 20:05, Tom Lane wrote: > I committed this with that change and some other > mostly-cosmetic revisions. Thanks. > Notable non-cosmetic changes: > > * I forced all the computed rscales to be at least 0, via code like > local_rscale =

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 13 November 2015 at 21:34, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 13 November 2015 at 18:36, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Next question: in the additional range-reduction step you added to ln_var, >> why stop there, ie, what's the rati

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 14 November 2015 at 16:13, Tom Lane wrote: >> We might well want to keep the power-10 argument reduction step, but >> it would now be there purely on performance grounds so there's scope >> for playing around with the threshold at which it kicks in. > > My inclination is to

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 12 November 2015 at 21:01, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> These results are based on the attached, updated patch which includes >> a few minor improvements. > > I started to look at this p

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 13 November 2015 at 18:36, Tom Lane wrote: > Next question: in the additional range-reduction step you added to ln_var, > why stop there, ie, what's the rationale for this magic number: > > if (Abs((x.weight + 1) * DEC_DIGITS) > 10) > > Seems like we arguably should

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 13 November 2015 at 21:00, Tom Lane wrote: > BTW, something I find confusing and error-prone is that this patch keeps > on using the term "weight" to refer to numbers expressed in decimal digits > (ie, the approximate log10 of something). Basically everywhere in the >

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 13 November 2015 at 23:10, Tom Lane wrote: > One more thing: the approach you used in power_var() of doing a whole > separate exp * ln(base) calculation to approximate the result weight > seems mighty expensive, even if it is done at minimal precision. > Couldn't we get a

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 14 November 2015 at 00:16, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > I can't see a way to make that work reliably. It would need to be > 10^estimate_ln_weight(base) and the problem is that both exp and > ln_weight could be too big to fit in double variables, and become >

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 11 November 2015 at 06:04, Michael Paquier wrote: >>> I also modified some of the CHECKFLOATVAL() checks which didn't look >>> right to me, unless there's some odd platform-specific behaviour that >>> I'm not aware of, functions like sin and asin should never return

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On 28 October 2015 at 16:50, Marko Tiikkaja wrote: > Hi, > > Here's a patch for the aggregate function outlined by Corey Huinker in > CADkLM=foA_oC_Ri23F9PbfLnfwXFbC3Lt8bBzRu3=cb77g9...@mail.gmail.com . +1. I've wanted something like this a few times. Of the names suggested so far,

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On 2 November 2015 at 10:59, Marko Tiikkaja <ma...@joh.to> wrote: > On 11/2/15 9:32 AM, Dean Rasheed wrote: >> >> On 28 October 2015 at 16:50, Marko Tiikkaja <ma...@joh.to> wrote: >>> >>> Here's a patch for the aggregate fun

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On 2 November 2015 at 09:10, Simon Riggs wrote: > I think we should avoid using ONLY or VALUE within the names since those > already have other meanings in Postgres. > We already have window functions called first_value, last_value and nth_value, so I think use of "value"

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 27 October 2015 at 08:24, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > I think it's still feasible to have sind(30) = 0.5 exactly and keep > monotonicity > Here's a patch along those lines. It turned out to be fairly straightforward. It's still basically a thin

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 22:51, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> Personally I'd rather have sind(30) be exactly 0.5, even if >> sind(29.999...) or sind(30.000...1) ended up the wrong side of it. > > TBH, s

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 18:58, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 26 October 2015 at 14:18, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ... but having said that, your argument here is faulty, beca

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 19:45, Peter Eisentraut <pete...@gmx.net> wrote: > On 10/24/15 5:24 AM, Dean Rasheed wrote: >> Additionally, functions that worked natively in degrees would be able >> to return exact answers in special cases like cosd(90) = 0, whereas >> cos(ra

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 20:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> I'm thinking something along the lines of: > >> 1. Reduce the range of the input (say to 0..90 degrees). >> 2. Handle special cases (0, 30

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 14:18, Tom Lane wrote: >> Having degree-based functions would make it trivial to implement >> user-defined gradian-based functions, just by multiplying or dividing >> by 0.9, and they would return exact results in the smaller number of >> cases where

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 25 October 2015 at 09:16, Emre Hasegeli wrote: >> Currently PostgreSQL only has trigonometric functions that work in >> radians. I think it would be quite useful to have an equivalent set of >> functions that worked in degrees. In other environments these are >> commonly

[HACKERS] Proposal: Trigonometric functions in degrees

Currently PostgreSQL only has trigonometric functions that work in radians. I think it would be quite useful to have an equivalent set of functions that worked in degrees. In other environments these are commonly spelled sind(), cosd(), etc. Partly, this would be a matter of convenience. It's

Re: [HACKERS] RLS bug in expanding security quals

On 8 October 2015 at 05:45, Haribabu Kommi wrote: > On Thu, Oct 8, 2015 at 2:54 PM, Stephen Frost wrote: >> It's quite late here, but I'll take a look at this in more depth >> tomorrow. >> >> Based on what the Assert's testing, I took an educated

Re: [HACKERS] RLS bug in expanding security quals

On 8 October 2015 at 15:05, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Attached is a simple patch that appears to work, but it needs more > testing (and some regression tests). > Here's an updated patch with an extra regression test case that triggers the issue. I'

Re: [HACKERS] unclear about row-level security USING vs. CHECK

On 28 September 2015 at 20:15, Stephen Frost wrote: > I listed out the various alternatives but didn't end up getting any > responses to it. I'm still of the opinion that the documentation is the > main thing which needs improving here, but we can also change CREATE > POLICY,

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

On 24 September 2015 at 21:25, Tom Lane wrote: > I wrote: >> - List *ri_WithCheckOptions; >> - List *ri_WithCheckOptionExprs; >> + List *ri_InsertedCheckClauses; >> + List *ri_InsertedCheckClauseExprs; > >> The distinction between a

Re: [HACKERS] Bug in numeric multiplication

On 21 September 2015 at 16:09, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Dean Rasheed <dean.a.rash...@gmail.com> writes: >>> The problem then arises in the final carry propagation pass. During >>> this phase of the computation, the carry from on

[HACKERS] Bug in numeric multiplication

Hi, By chance, while testing the nearby numeric log/exp/pow patch, I came across the following case which generates an initially puzzling looking error on HEAD -- (5.6-1e-500) ^ (3.2-1e-200). This computation actually works OK with that other patch, but only by blind luck. It turns out that the

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 16 September 2015 at 14:49, Merlin Moncure wrote: >> AFAICT, this kind of slowdown only happens in cases like this where a >> very large number of digits are being returned. > > Can you clarify "very large"? > I haven't done much performance testing because I've been

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 16 September 2015 at 16:14, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 16 September 2015 at 14:49, Merlin Moncure <mmonc...@gmail.com> wrote: >>> AFAICT, this kind of slowdown only happens in cases like this where a >>> very large number of digits

Re: [HACKERS] RLS open items are vague and unactionable

On 15 September 2015 at 15:22, Stephen Frost wrote: > Updated patch attached for review. > > Unless there are other concerns or issues raised, I'll push this later > today. > Looks good to me. Thanks for doing all this. Regards, Dean -- Sent via pgsql-hackers mailing list

Re: [HACKERS] RLS open items are vague and unactionable

On 14 September 2015 at 14:47, Stephen Frost wrote: > Attached is a git format-patch built series which includes both commits, > now broken out, for review. > That looks OK to me. A minor point -- this comment isn't quite right: /* * For the target relation, when

Re: [HACKERS] RLS open items are vague and unactionable

On 13 September 2015 at 22:54, Stephen Frost wrote: > Not in front of my laptop and will review it when I get back in more detail, > but the original approach that I tried was changing > get_policies_for_relation to try and build everything necessary, which > didn't work as we

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 15:51, Joe Conway <m...@joeconway.com> wrote: > On 09/11/2015 04:33 AM, Stephen Frost wrote: >> * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >>> I will happily work up a rebased version of the patch, but only if I >>> get a serious comm

Re: [HACKERS] RLS open items are vague and unactionable

On 13 September 2015 at 20:59, Stephen Frost wrote: > I've been through this and definitely like it more than what we had > previously, as I had mentioned previously. I've also added the > RETURNING handling, per the discussion between you, Robert, Tom, and > Kevin. > > Would

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 17:56, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 11 September 2015 at 15:49, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> However, I don't see why UPDATE/DELETE with RETURNING couldn't

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 15:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> Yeah, we had a similar discussion regarding UPDATE USING policies and >> ON CONFLICT UPDATE clauses. I think the argument against filtering is >

Re: [HACKERS] RLS open items are vague and unactionable

On 10 September 2015 at 21:48, Robert Haas wrote: > The open items list here: > > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items > > Dean's latest round of RLS refactoring. This refactoring patch doesn't fix any behavioural issues. It is all about trying to

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 13:05, Robert Haas wrote: > Thanks for the updates. My thoughts: > > On RETURNING, it seems like we've got a fairly fundamental problem > here. If I understand correctly, the intention of allowing policies > to be filtered by command type is to

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 15:20, Stephen Frost <sfr...@snowman.net> wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> I think blind updates are a pretty niche case, and I think that it >> wasn't the intention to support them, but more of an uninten

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

On 27 August 2015 at 18:44, Andres Freund and...@anarazel.de wrote: On 2015-08-27 18:37:10 +0100, Dean Rasheed wrote: I have a feeling that RLS might suffer from the same issue, but I haven't looked yet. There's a similar issue there, yes: http://archives.postgresql.org/message-id

Re: [HACKERS] AcquireRewriteLocks/acquireLocksOnSubLinks vs. rowsecurity

On 27 August 2015 at 13:49, Andres Freund and...@anarazel.de wrote: Hi, The locking around rowsecurity policy expressions seems to be insufficient: SELECT * FROM document WHERE f_leak(dtitle) ORDER BY did; WARNING: RelationIdGetRelation(247984) without holding lock on the relation WARNING:

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

On 27 August 2015 at 12:18, Andres Freund and...@anarazel.de wrote: On 2013-10-24 20:58:55 +0100, Dean Rasheed wrote: So I think the only thing missing from rewriteTargetView() is to lock any relations from any sublink subqueries in viewquery using acquireLocksOnSubLinks() -- patch attached

Re: [HACKERS] missing locking in at least INSERT INTO view WITH CHECK

On 27 August 2015 at 19:29, Andres Freund and...@anarazel.de wrote: On 2015-08-27 19:19:35 +0100, Dean Rasheed wrote: It also seems to me that this warning has proved its worth Same here - I plan to re-submit it. Perhaps the number of bugs it found convinces Tom, after I address some of his

Re: [HACKERS] RLS restrictive hook policies

On 3 August 2015 at 16:09, Stephen Frost sfr...@snowman.net wrote: Dean, all, * Stephen Frost (sfr...@snowman.net) wrote: Agreed. I'm happy to commit that change and back-patch it to 9.5, barring objections. Given that the only way to have restrictive policies currently is using hooks, I

[HACKERS] RLS restrictive hook policies

In get_row_security_policies(): /* * If the only built-in policy is the default-deny one, and hook policies * exist, then use the hook policies only and do not apply the * default-deny policy. Otherwise, we will apply both sets below. */ if (defaultDeny

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

On 30 July 2015 at 01:35, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2015 02:21 AM, Dean Rasheed wrote: While going through this, I spotted another issue --- in a DML query with additional non-target relations, such as UPDATE t1 .. FROM t2

Re: [HACKERS] more RLS oversights

On 29 July 2015 at 16:52, Joe Conway joe.con...@crunchydata.com wrote: On 07/29/2015 02:41 AM, Dean Rasheed wrote: I don't think there is any point in adding the new function transformPolicyClause(), which is identical to transformWhereClause(). You can just use transformWhereClause

Re: [HACKERS] more RLS oversights

On 29 July 2015 at 20:36, Joe Conway joe.con...@crunchydata.com wrote: On 07/29/2015 02:41 AM, Dean Rasheed wrote: I don't think there is any point in adding the new function transformPolicyClause(), which is identical to transformWhereClause(). You can just use transformWhereClause

Re: [HACKERS] more RLS oversights

On 29 July 2015 at 02:36, Joe Conway joe.con...@crunchydata.com wrote: On 07/03/2015 10:03 AM, Noah Misch wrote: (6) AlterPolicy() calls InvokeObjectPostAlterHook(PolicyRelationId, ...), but CreatePolicy() and DropPolicy() lack their respective hook invocations. Patch attached. Actually

Re: [HACKERS] more RLS oversights

On 29 July 2015 at 05:02, Joe Conway joe.con...@crunchydata.com wrote: On 07/03/2015 10:03 AM, Noah Misch wrote: (7) Using an aggregate function in a policy predicate elicits an inapposite error message due to use of EXPR_KIND_WHERE for parse analysis. Need a new ParseExprKind. Test case:

Re: [HACKERS] A little RLS oversight?

On 28 July 2015 at 03:19, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 03:05 PM, Stephen Frost wrote: AFK at the moment, but my thinking was that we should avoid having the error message change based on what a GUC is set to. I agree that

Re: [HACKERS] A little RLS oversight?

On 27 July 2015 at 21:58, Stephen Frost sfr...@snowman.net wrote: Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: On 27 July 2015 at 18:13, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 10:03 AM, Joe Conway wrote: On 07/26

Re: [HACKERS] A little RLS oversight?

On 27 July 2015 at 18:13, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 10:03 AM, Joe Conway wrote: On 07/26/2015 07:59 AM, Joe Conway wrote: On 07/26/2015 07:19 AM, Dean Rasheed wrote: Attached is an updated patch (still needs some docs

Re: [HACKERS] A little RLS oversight?

On 27 July 2015 at 22:36, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 01:25 PM, Dean Rasheed wrote: Looks good to me, except I'm not sure about those latest changes because I don't understand the reasoning behind the logic

Re: [HACKERS] A little RLS oversight?

On 25 July 2015 at 19:12, Joe Conway joe.con...@crunchydata.com wrote: On 07/22/2015 02:17 PM, Dean Rasheed wrote: Hmm, I think it probably ought to do more, based on whether or not RLS is being bypassed or in force-mode -- see the first few checks in get_row_security_policies(). Perhaps a new

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 3 July 2015 at 20:50, Tom Lane t...@sss.pgh.pa.us wrote: Petr Korobeinikov pkorobeini...@gmail.com writes: Fixed. Now both \ev and \sv numbering lines starting with 1. New version attached. Applied with a fair amount of mostly-cosmetic adjustment. As I've already noticed that

Re: [GENERAL] [9.5] next question: rls and indexes

On 15 July 2015 at 09:34, Andreas Kretschmer akretsch...@spamfence.net wrote: test= explain select * from rls_test ; QUERY PLAN - Seq Scan on rls_test (cost=0.00..630.00 rows=91 width=335) Filter: (name

Re: [HACKERS] RLS fails to work with UPDATE ... WHERE CURRENT OF

On 14 July 2015 at 13:59, Robert Haas robertmh...@gmail.com wrote: On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway m...@joeconway.com wrote: On 06/08/2015 02:08 AM, Dean Rasheed wrote: Actually I think it is fixable just by allowing the CURRENT OF expression to be pushed down into the subquery

Re: [HACKERS] WIP: ALTER TABLE ... ALTER CONSTRAINT ... SET DEFERRABLE on UNIQUE or PK

On 26 June 2015 at 07:20, Craig Ringer cr...@2ndquadrant.com wrote: Hi all Attached is a patch to implement ALTER TABLE ... ALTER CONSTRAINT ... SET DEFERRABLE on UNIQUE or PRIMARY KEY constraints. Currently only FOREIGN KEY constraints are supported. Others are rejected with: +1 I was

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro thomas.mu...@enterprisedb.com wrote: We saw a rather extreme performance problem in a cluster upgraded from

[HACKERS] CREATE FUNCTION .. LEAKPROOF docs

I think the docs for the LEAKPROOF option in create_function.sgml ought to mention RLS as well as security barrier views. Also the current text is no longer strictly correct in light of commit dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording attached. Regards, Dean diff --git

Re: [HACKERS] 9.5 release notes

On 11 June 2015 at 05:15, Bruce Momjian br...@momjian.us wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html I think it's worth mentioning dcbf5948e12aa60b4d6ab65b6445897dfc971e01, probably

[DOCS] Minor typo in rules.sgml

There's a minor grammatical typo in the description of leakproof functions (going back to 9.2). Patch attached. Regards, Dean diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml new file mode 100644 index cb5c8fc..720f976 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@

Re: [HACKERS] CREATE POLICY and RETURNING

On 8 June 2015 at 16:53, Stephen Frost sfr...@snowman.net wrote: I definitely don't like the idea of returning a portion of the data in a RETURNING clause. Returning an error if the RETURNING clause ends up not passing the SELECT policy is an interesting idea, but I do have doubts about how

<    5   6   7   8   9   10   11   12   13   14   >