Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/05/2015 10:48 AM, Pavel Stehule wrote: > S > tC > a<>E > rA B A B A n > t d > |====---| > > Currently we can set timeout and cancel

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

On 11/05/2015 12:56 PM, Pavel Stehule wrote: > 2015-11-05 17:17 GMT+01:00 Joe Conway wrote: > Hey, I resemble that remark ;-) > > I am sorry, Joe - no any personal attack - I'll pay a beer for you if > you visit Prague :) No offense taken, but I might take you up on th

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:24 PM, Alvaro Herrera wrote: > I agree with Pavel. Having a transaction timeout just does not make any > sense. I can see absolutely no use for it. An idle-in-transaction > timeout, on the other hand, is very useful. +1 -- agreed Joe -- Crunchy Data - http://crunchydata.com

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 02:07 PM, Joshua D. Drake wrote: > On 11/04/2015 01:55 PM, Stephen Frost wrote: >> * Joe Conway (m...@joeconway.com) wrote: >>> On 11/04/2015 01:24 PM, Alvaro Herrera wrote: >>>> I agree with Pavel. Having a transaction timeout just does not make &

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

On 11/04/2015 04:09 AM, Pavel Stehule wrote: > I am looking on this last patch. I talked about the name of this command > with more people, and the name "rotate" is unhappy. The correct name for > this visualization technique is "crosstab" (see google "crosstab"). The > conflict with our extension

Re: [HACKERS] ALTER SYSTEM vs symlink

On 11/02/2015 09:24 AM, Stephen Frost wrote: > I certainly look forward to having more fine grained control, to the > point where I'd like to be able to run a system reasonably without an > active superuser login. Having superusers logging into production > running databases is extremely

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 10/30/2015 06:53 AM, Erik Rijkers wrote: >> [2015082503-pgconfig_controldata.diff] > > I tried to build this, and the patch applies cleanly but then a ld error > emerges: I'm sure the patch would need to be rebased, but the last thread died with significant complaints and questions about what

Re: [HACKERS] ALTER SYSTEM vs symlink

On 11/02/2015 08:33 AM, Stephen Frost wrote: > A deeper hook in the ALTER SYSTEM might be another approach, or one > in the GUC system to allow external libraries to control what various > GUCs can be set to (either via ALTER SYSTEM or through regular SET > calls). I have run into multiple

[HACKERS] Re: [BUGS] BUG #13694: Row Level Security by-passed with CREATEUSER permission

On 10/21/2015 12:46 PM, Tom Lane wrote: > Attached patch rips out CREATEUSER and NOCREATEUSER options lock, stock, > and barrel. Looks good to me. > Another possibility is to change them to actually mean CREATEROLE and > NOCREATEROLE. I think probably a clean break is better though. I think

Re: [HACKERS] dblink: add polymorphic functions.

On 07/30/2015 09:51 AM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> What about just TYPE then? > >> SELECT x::TYPE(some_expression) FROM ... >> SELECT CAST (x AS TYPE(some_expression)) FROM ... > The main limitation of this patch is

[HACKERS] Proposal: SET ROLE hook

In many environments there is a policy requiring users to login using unprivileged accounts, and then escalate their privileges if and when they require it. In PostgreSQL this could be done by granting the superuser role to an unprivileged user with noinherit, and then making the superuser role

Re: [HACKERS] Proposal: SET ROLE hook

On 10/16/2015 09:28 AM, Andres Freund wrote: > Alternatively you can just have a elevate_user() function that does the > logging and escalating? That seems like the same amount of code and it'd > work with released versions of postgres? > > Sure, that has some disadvantages over your approach,

Re: [HACKERS] Multi-tenancy with RLS

On 10/08/2015 11:04 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> We've got one reloption for views already - security_barrier. Maybe >> we could have another one that effectively changes a particular view >> from "security definer" as it is today to "security

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

On 10/05/2015 06:02 AM, Heikki Linnakangas wrote: > There was prior discussion on the EVP API in this old thread from 2007: > http://www.postgresql.org/message-id/flat/46a5e284.7030...@sun.com#46a5e284.7030...@sun.com > > > In short, pgcrypto actually used to use the EVP functions, but was >

[HACKERS] SESSION SESSION - bug or intentional?

I was looking at something in gram.y when I noticed that the following production works: SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ ONLY; "SESSION SESSION" seems fairly odd -- is it intentional? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure

Re: [HACKERS] Idea for improving buildfarm robustness

On 09/29/2015 01:48 PM, Alvaro Herrera wrote: > Joe Conway wrote: >> On 09/29/2015 12:47 PM, Tom Lane wrote: >>> We could possibly add additional checks, like trying to verify that >>> pg_control has the same inode number it used to. But I'm afraid that >>> wo

Re: [HACKERS] Idea for improving buildfarm robustness

On 09/29/2015 12:47 PM, Tom Lane wrote: > We could possibly add additional checks, like trying to verify that > pg_control has the same inode number it used to. But I'm afraid that > would add portability issues and false-positive hazards that would > outweigh the value. Not sure you remember

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/25/2015 09:32 AM, Tom Lane wrote: > 2. There's no visibility for outsiders as to what issues are open or > recently fixed. Not being outsiders, I'm not sure that we are terribly > well qualified to describe this problem precisely or identify a good > solution --- but I grant that there's a

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/24/2015 10:08 AM, Stephen Frost wrote: > debbugs does most of the above by default, no programming needed... I'm > sure we could get it to integrate with the commitfest and have a git > commit hook which sends the appropriate email to it also. > > That the emacs folks are using it makes me

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/23/2015 05:21 PM, Thomas Munro wrote: > Do you think it would make any sense to consider evolving what we have > already? At the moment, we have a bug form, and when you submit it it > does this (if I'm looking at the right thing, please correct me if I'm > not): > >

Re: [HACKERS] One question about security label command

On 09/15/2015 11:36 AM, Joe Conway wrote: > On 09/13/2015 10:29 AM, Kouhei Kaigai wrote: >> The attached one is the regression test fixup in v9.2. >> As we applied to the v9.3 or later, it replaces unconfined_t domain >> by the self defined sepgsql_regtest_superuser_t.

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/18/2015 09:25 AM, Adam Brightwell wrote: >>> 1. remove row_security=force >>> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to >>> policies >>> 3. add DDL-controlled, per-table policy forcing >>> >>> They ought to land in that order. PostgreSQL 9.5 would need at least

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/18/2015 01:07 AM, Noah Misch wrote: > Great. Robert, does that work for you, too? If so, this sub-thread is > looking at three patches: > > 1. remove row_security=force > 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies > 3. add DDL-controlled, per-table

Re: [HACKERS] One question about security label command

On 09/13/2015 10:29 AM, Kouhei Kaigai wrote: > The attached one is the regression test fixup in v9.2. > As we applied to the v9.3 or later, it replaces unconfined_t domain > by the self defined sepgsql_regtest_superuser_t. > > Unfortunately, I found a bug to process SELECT INTO statement. >

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/15/2015 12:53 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> There are use cases where row_security=force will be set in production >> environments, not only in testing. > > What cases, exactly, and is there another way to solve those probl

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/15/2015 10:58 AM, Robert Haas wrote: > I can't argue with that, I suppose, but I think row_security=force is > a pretty useful convenience. If we must remove it, so be it, but I'd > be a little sad. There are use cases where row_security=force will be set in production environments, not

Re: [HACKERS] row_security GUC, BYPASSRLS

On 09/15/2015 11:10 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote: >>> It also requires a DBA unwilling to >>> furnish test accounts to custodians of sensitive data. With or without >>>

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

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 commitment from a committer to review it. Otherwise, >> I'll let it drop. > > There's no question about getting

Re: [HACKERS] Multi-tenancy with RLS

On 09/01/2015 11:25 PM, Haribabu Kommi wrote: > If any user is granted any permissions on that object then that user > can view it's meta data of that object from the catalog tables. > To check the permissions of the user on the object, instead of > checking each and every available option, I just

Re: [HACKERS] Modernizing contrib/tablefunc

On 09/09/2015 03:03 PM, David Fetter wrote: > Folks, > > While doing some research for the upcoming (UN)PIVOT proposal, I > noticed that there were some hairy and no-longer-needed bits in the > regression tests for tablefunc, which I have shaved off with the > attached patch. > > What say? Is

Re: [HACKERS] One question about security label command

On 08/30/2015 11:17 AM, Joe Conway wrote: >>> 3.) Rework patch for 9.2 (Kohei) >>> 4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to >>> test sepgsql on 9.2 and up. The animal (rhinoceros) is running >>> already, but still needs some cu

Re: [HACKERS] One question about security label command

On 09/07/2015 04:46 PM, Kouhei Kaigai wrote: > 3.) Rework patch for 9.2 (Kohei) >> > Could you wait for the next Monday? > I'll try to work this in the next weekend. Sure, that would be great. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises

Re: [HACKERS] PL/pgSQL, RAISE and error context

On 09/05/2015 09:14 AM, Joe Conway wrote: > On 09/05/2015 09:05 AM, Tom Lane wrote: >> I wrote: >>> If there are not major objections, I'll work on cleaning up and >>> committing the patch. >> >> Pushed. I'm not too sure about the expected outputs for py

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/02/2015 02:54 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> On 09/02/2015 02:34 PM, Alvaro Herrera wrote: >>> I think trying to duplicate the exact strings isn't too nice an >>> interface. >> >> Well, for pg_controldata, no, but what else would you do for pg_config? > > I was primarily

Re: [HACKERS] PL/pgSQL, RAISE and error context

On 09/05/2015 09:05 AM, Tom Lane wrote: > I wrote: >> If there are not major objections, I'll work on cleaning up and >> committing the patch. > > Pushed. I'm not too sure about the expected outputs for python other > than 2.6, nor for sepgsql, but hopefully the buildfarm will provide >

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/02/2015 05:25 PM, Tom Lane wrote: > Robert Haas writes: >> But I'm not sure I like the idea of adding a server dependency on >> the ability to exec pg_controldata. That seems like it could be >> unreliable at best, and

Re: [HACKERS] One question about security label command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/28/2015 07:21 PM, Adam Brightwell wrote: On 08/28/2015 08:37 AM, Joe Conway wrote: So given all that, here is what I propose we do: 1.) Commit Kouhei's patch against HEAD and 9.5 (Joe) 2.) Commit my modified patch against 9.4 and 9.3 (Joe

Re: [HACKERS] One question about security label command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 06:54 PM, Joe Conway wrote: On 08/25/2015 06:03 PM, Joe Conway wrote: I'm arriving late to this party, so maybe everyone else already knows this, but apparently sepgsql is not compatible with the version of selinux available

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2015 06:33 AM, Stephen Frost wrote: * Joe Conway (m...@joeconway.com) wrote: Issues needing comment: a.) Which items need hiding from non-superusers and should the value be redacted or the entire result set row be suppressed? I'm

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2015 07:41 PM, Tom Lane wrote: Joe Conway m...@joeconway.com writes: Do we care that as of 9.5 pg_controldata output is not 100% aligned anymore? The culprit is: Current track_commit_timestamp setting: off Its value is shifted 2

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 10:28 AM, Tom Lane wrote: Joe Conway m...@joeconway.com writes: On 08/24/2015 07:41 PM, Tom Lane wrote: Seems to me we could s/Current //g, or s/ setting//g, or both, and get rid of the problem without adding more whitespace. I'd

Re: [HACKERS] Commitfest remaining Needs Review items

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 12:39 AM, Michael Paquier wrote: -- self-defined policy for sepgsql regression test, returned with feedback? The regressions are broken as mentioned at the end of the thread. I am in the process of getting a VM setup with an

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2015 08:52 AM, Joe Conway wrote: On 08/24/2015 06:50 AM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 08/23/2015 08:58 PM, Michael Paquier wrote: I think that's a good thing to have, now I have concerns about making

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 10:32 AM, Joe Conway wrote: On 08/25/2015 10:28 AM, Tom Lane wrote: I was suggesting getting rid of Current in *all* the entries. What value does it add? I agree, it adds no value, and is a simple solution. Does anyone out

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 11:28 AM, Alvaro Herrera wrote: Joe Conway wrote: Does anyone out there object to a non-backward compatible change to pg_controldata output? I don't (and thanks for taking care of it), but as I recall, pg_upgrade reads

Re: [HACKERS] One question about security label command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 01:02 PM, Stephen Frost wrote: * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote: So what about the buildfarm animal that was offered for this? We still have this module completely uncovered in the buildfarm ...

Re: [HACKERS] One question about security label command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 02:27 PM, Joe Conway wrote: On 08/25/2015 01:02 PM, Stephen Frost wrote: * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote: So what about the buildfarm animal that was offered for this? We still have this module

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 12:41 PM, Alvaro Herrera wrote: Joe Conway wrote: On 08/25/2015 11:28 AM, Alvaro Herrera wrote: Joe Conway wrote: Does anyone out there object to a non-backward compatible change to pg_controldata output? I don't (and thanks

Re: [HACKERS] One question about security label command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 06:03 PM, Joe Conway wrote: I'm arriving late to this party, so maybe everyone else already knows this, but apparently sepgsql is not compatible with the version of selinux available on RHEL 6.x. So there doesn't seem to be much

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2015 06:50 AM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 08/23/2015 08:58 PM, Michael Paquier wrote: I think that's a good thing to have, now I have concerns about making this data readable for non-superusers. Cloud

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2015 04:38 AM, Andrew Dunstan wrote: On 08/23/2015 08:58 PM, Michael Paquier wrote: + Datum pg_config(PG_FUNCTION_ARGS); + + PG_FUNCTION_INFO_V1(pg_config); The declaration of the function is not needed, PG_FUNCTION_INFO_V1 takes care

[HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Do we care that as of 9.5 pg_controldata output is not 100% aligned anymore? The culprit is: Current track_commit_timestamp setting: off Its value is shifted 2 characters to the right with respect to all the others. I think it ought to be fixed

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2015 07:54 AM, Joe Conway wrote: On 08/20/2015 06:59 AM, Andrew Dunstan wrote: I was a bit interested in pg_config information, for this reason: I had a report of someone who had configured using --with-libxml but the xml tests actually

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2015 06:59 AM, Andrew Dunstan wrote: Is there any significant interest in either of these? Josh Berkus tells me that he would like pg_controldata information, and I was a bit interested in pg_config information, for this reason: I had a

Re: [HACKERS] [patch] A \pivot command for psql

the conversation again, especially at this stage of the 9.6 cycle, is a very good thing, whatever its outcome. Talk to Atri Sharma -- he recently indicated to me that he might be working on built-in pivot in the near term future (if not already started). - -- Joe Conway Crunchy Data Enterprise

Re: [HACKERS] [patch] A \pivot command for psql

-returning function? That's exactly what crosstab() in the tablefunc contrib module is. I've heard rumblings of someone looking to build crosstab/pivot into the core grammar, but have not yet seen any patches... Joe - -- Joe Conway Crunchy Data Enterprise PostgreSQL http://crunchydata.com

Re: [HACKERS] WIP: SCRAM authentication

say the password is encrypted when, at least currently, it is a simple hash (cryptographic hash yes, but not encrypted, and not even an HMAC). I think we should try to start using accurate terminology. - -- Joe Conway Crunchy Data Enterprise PostgreSQL http://crunchydata.com -BEGIN PGP SIGNATURE

Re: [HACKERS] Draft Alpha 2 announcement

- -- Joe Conway Crunchy Data Enterprise PostgreSQL http://crunchydata.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVwkf1AAoJEDfy90M199hlEnwP/RNObNwpdzN9MxWTEzLQfB5o PdQ4kjE4tY/PdYrLv2G7a12G9i/Lfkza1grHc+FaAuc7QPToOPLEut/punZgPlU2

Re: [HACKERS] 64-bit XIDs again

similar lines to both of you for quite some time now. I think at the least we should explore an initdb time option - -- we can and should measure the pros and cons. - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVujVzAAoJEDfy90M199hlphUP/j/+TEJO05h

Re: [HACKERS] CREATE FUNCTION .. LEAKPROOF docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 04:46 PM, Joe Conway wrote: On 06/14/2015 03:46 AM, Dean Rasheed wrote: 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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2015 06:52 AM, Dean Rasheed wrote: On 30 July 2015 at 01:35, Joe Conway m...@joeconway.com wrote: 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

Re: [HACKERS] dblink: add polymorphic functions.

to calculate it, no? - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVuPv8AAoJEDfy90M199hlYCwP/i0/berqnjXFch6zFM5TDZ6h +UxQxMmVg933U6Cdoc+huMz8Hiotix76BZVgHOa8xI7Vktx1y5D7o7auczg31v4o BkzbJFX9ziK5TXZm5wEvtTPNJOOq25AqvHzmrwr4JnPvyAOCKQASTqhIi95mdflZ tGI

Re: [HACKERS] more RLS oversights

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() with EXPR_KIND_POLICY. It's already used for lots of other expression kinds.

Re: [HACKERS] more RLS oversights

On 07/29/2015 08:46 AM, Joe Conway wrote: On 07/29/2015 01:01 AM, Dean Rasheed wrote: The CreatePolicy() and AlterPolicy() changes look OK to me, but the RemovePolicyById() change looks to be unnecessary --- RemovePolicyById() is called only from doDeletion(), which in turned is called only

Re: [HACKERS] more RLS oversights

On 07/29/2015 01:01 AM, Dean Rasheed wrote: The CreatePolicy() and AlterPolicy() changes look OK to me, but the RemovePolicyById() change looks to be unnecessary --- RemovePolicyById() is called only from doDeletion(), which in turned is called only from deleteOneObject(), which already

Re: [HACKERS] more RLS oversights

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() with EXPR_KIND_POLICY. It's already used for lots of other expression kinds.

Re: [HACKERS] more RLS oversights

On 07/29/2015 02:56 PM, Joe Conway wrote: On 07/29/2015 02:04 PM, Alvaro Herrera wrote: Why not just in policy expressions? There's no third kind that does allow these. WFM Sold! Will do it that way. Committed/pushed to HEAD and 9.5. Joe -- Sent via pgsql-hackers mailing list

Re: [HACKERS] more RLS oversights

On 07/29/2015 01:26 PM, Robert Haas wrote: On Wed, Jul 29, 2015 at 3:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I think this reads a bit funny. What's a POLICY USING clause? I expect that translators will treat the two words POLICY USING as a single token, and the result is not

Re: [HACKERS] more RLS oversights

On 07/29/2015 02:04 PM, Alvaro Herrera wrote: Why not just in policy expressions? There's no third kind that does allow these. WFM Sold! Will do it that way. Joe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 09:40 AM, Corey Huinker wrote: Say I've got a table my_partitioned_table (key1 integer, key2 integer, metric1 integer, metric2 integer); And I've got many partitions on that table. My code lets you do something like this: select

Re: [HACKERS] CREATE FUNCTION .. LEAKPROOF docs

dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording attached. Any objections out there to this doc patch? It rings true and reads well to me. I'd like to check another item off the 9.5 Open Items list.. . - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux

Re: [HACKERS] dblink: add polymorphic functions.

with %TYPE). You think this could be made to work? SELECT x::TYPE OF(some_expression) FROM ... Then we would also have: SELECT CAST(x AS TYPE OF(some_expression)) FROM ... Seems nicer than pg_typeof - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux

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

-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 .., the old code was checking the UPDATE policies of both t1 and

Re: [HACKERS] dblink: add polymorphic functions.

with the special case in LookupTypeName. It's just a matter of picking a word people like. What about just TYPE then? SELECT x::TYPE(some_expression) FROM ... SELECT CAST (x AS TYPE(some_expression)) FROM ... - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux

Re: [HACKERS] more RLS oversights

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 AlterPolicy() was also missing its hook -- the existing

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 05:34 PM, Joe Conway wrote: On 07/27/2015 01:13 PM, Alvaro Herrera wrote: Hmm, these are not ACL objects, so conceptually it seems cleaner to use a different symbol for this. I think the catalog state and the error messages would

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: (4) When DefineQueryRewrite() is about to convert a table to a view, it checks the table for features unavailable to views. For example, it rejects tables having triggers. It omits to reject tables having relrowsecurity or a pg_policy record. Test

Re: [HACKERS] more RLS oversights

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: Patch attached. Comments? Joe diff --git

Re: [HACKERS] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 12:32 AM, Dean Rasheed wrote: 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 there should be

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 11:50 AM, Stephen Frost wrote: * Joe Conway (joe.con...@crunchydata.com) wrote: On 07/03/2015 10:03 AM, Noah Misch wrote: (4) When DefineQueryRewrite() is about to convert a table to a view, it checks the table for features

Re: [HACKERS] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 11:17 AM, Joe Conway wrote: I'm going to commit the attached in the next few hours unless someone has serious objections. We can always revisit the specific behavior of those messages separately if we change our minds... Pushed

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

, though. Should we take it as it is, or wait for some cleaner approach? Put like that, it does sound quite ugly. I take it we have no better alternative proposed? Joe Conway suggested a more generic approach here: http://www.postgresql.org/message-id/559a9643.9070...@joeconway.com. I'm

Re: [HACKERS] A little RLS oversight?

-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 for the functions). Thanks for that. I'll add the docs

Re: [HACKERS] A little RLS oversight?

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 for the functions). Thanks for that. I'll add the docs. Documentation added. Also added comment to check_enable_rls about passing InvalidOid versus

Re: [HACKERS] A little RLS oversight?

depending on row_security for users with BYPASSRLS. I think if we do the former (original coding) there should probably be a comment added to indicate we are doing that intentionally. Thoughts? - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux

Re: [HACKERS] A little RLS oversight?

RLS_ENABLED we never reset has_perm to false, and thus leak info even though the comments claim we don't. I fixed that here, but someone please take a look and confirm I am reading that correctly. Beyond that, any additional comments? Thanks, Joe - -- Joe Conway -BEGIN PGP SIGNATURE

Re: [HACKERS] more RLS oversights

Isn't this leaking the previously allocated array? Not sure it's all that critical, but still. (I don't think you really need to call palloc at all here.) Agreed -- I think the attached is a bit cleaner. Any other comments or concerns? - -- Joe Conway -BEGIN PGP SIGNATURE- Version

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: +static void +dumpPolicy(Archive *fout, PolicyInfo *polinfo) ... +if (polinfo-polqual != NULL) +appendPQExpBuffer(query, USING %s, polinfo-polqual); (3) The USING clause needs parentheses; a dump+reload failed like so: Also needed

Re: [HACKERS] A little RLS oversight?

On 07/26/2015 07:19 AM, Dean Rasheed wrote: I'm not convinced about exporting convert_table_name() from acl.c, particularly with such a non-descriptive name. It's only a couple of lines of code, so I think they may as well just be included directly in the new function, as seems to be common

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/03/2015 10:03 AM, Noah Misch wrote: (2) CreatePolicy() and AlterPolicy() omit to create a pg_shdepend entry for each role in the TO clause. Test case: Please see the attached patch. Note that I used SHARED_DEPENDENCY_ACL for this. It seems

Re: [HACKERS] markup problems in row_security GUC docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2015 03:26 PM, Kevin Grittner wrote: The use of the apostrophe character to quote allowed enumerated values seems wrong. Probably these should be replaced by literal tags. The reference to BYPASSRLS also seems like it deserves markup,

Re: [HACKERS] A little RLS oversight?

On 07/22/2015 02:17 PM, Dean Rasheed wrote: On 21 July 2015 at 04:53, Michael Paquier michael.paqu...@gmail.com wrote: On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost sfr...@snowman.net wrote: We need to be careful to avoid the slippery slope of trying to prevent all covert channels, which has

Re: [HACKERS] markup problems in row_security GUC docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2015 04:17 PM, Joe Conway wrote: On 07/25/2015 03:26 PM, Kevin Grittner wrote: The use of the apostrophe character to quote allowed enumerated values seems wrong. Probably these should be replaced by literal tags. The reference

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/14/2015 12:40 PM, Dean Rasheed wrote: 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

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2015 06:15 PM, Noah Misch wrote: On Fri, Jul 10, 2015 at 03:08:53PM -0700, Joe Conway wrote: On 07/03/2015 10:03 AM, Noah Misch wrote: (1) CreatePolicy() and AlterPolicy() omit to call assign_expr_collations() on the node trees

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: (1) CreatePolicy() and AlterPolicy() omit to call assign_expr_collations() on the node trees. Test case: begin; set row_security = force; create table t (c) as values ('bar'::text); create policy p on t using (c ('foo'::text COLLATE C)); alter

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2015 10:22 PM, Michael Paquier wrote: On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway m...@joeconway.com wrote: That explains why the first example works while the second does not. I'm not sure how hard it would be to fix

Re: [HACKERS] dblink: add polymorphic functions.

is that jsonb_to_recordset() does not behave like these new dblink functions in that it requires a runtime column definition list. It might be better to use something completely different, so I think _any() or maybe _to_any() is better. Any other ideas for names out there? Joe - -- Joe Conway -BEGIN PGP

Re: [HACKERS] Improving regression tests to check LOCK TABLE and table permissions

and pushed to master and 9.5 Joe - -- Joe Conway -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVnEcNAAoJEDfy90M199hlqTwP/0w87jIaAiJ86w+B72w24InP 77HYMqHd/6IB7cx6JWvDxeYZB0UN0h66A6z7TxaRyVCGM3m2ak73GwH+hj23TO9p xCn94ZAFN4jfnFoiHAHQqThMlschbGFpvDbSxDyCbRyMV0t9ztpg+/bE/9

Re: [HACKERS] Redundant error messages in policy.c

the language around policy vs. row security vs. row level security, but didn't look as closely as I should have at the error messages overall. Will address. Pushed. Needed a small change to the expected regression output to match . Joe - -- Joe Conway -BEGIN PGP SIGNATURE- Version

<    1   2   3   4   5   6   7   8   9   10   >