On 11/05/2015 10:09 AM, Pavel Stehule wrote:
> On 5.11.2015 19:02 Merlin Moncure wrote:
>> Thus, I think we have consensus that transaction_timeout is good -- it
>> would deprecate statement_timeout essentially. Likewise,
>> pg_cancel_transaction is good and would deprecate pg_cancel_backend;
>> i
On 11/04/2015 10:46 PM, Pavel Stehule wrote:
> 2015-11-05 7:39 GMT+01:00 Craig Ringer wrote:
> I see constant confusion between \copy and COPY. It's a really good
> reason NOT to overload other psql commands IMO.
>
> but crosstab is one old function from old extension with unfriendly
> des
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
&
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
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
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 situat
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 dangerous
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
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 th
On 07/30/2015 09:51 AM, Tom Lane wrote:
> Joe Conway 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 that it won't work f
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, but
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 nol
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 invoker"
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
> chan
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 Enterpris
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
>>&g
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 the
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 p
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
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):
>
> http://git.postgresql.o
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.
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 (1
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 policy
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.
> Becaus
On 09/15/2015 12:53 PM, Tom Lane wrote:
> Joe Conway 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 problems?
> I concur with Noah
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
>>> row_security=force, such a team is on the outer perimeter of
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 onl
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 i
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
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 th
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
Consulting,
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
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 l
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 outp
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
> feedback.
-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 a security vulnerability
-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
>> m
-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
>> ve
-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
-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 writes:
>>> On 08/23/2015 08:58 PM, Michael Paquier wrote:
>>>> I think that's a good thing to have, now I have c
-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'
-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 compatib
-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 f
-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
>
-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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 10:28 AM, Tom Lane wrote:
> Joe Conway 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/24/2015 07:41 PM, Tom Lane wrote:
> Joe Conway 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 shifte
-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 appro
-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 but
-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 t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/24/2015 06:50 AM, Tom Lane wrote:
> Andrew Dunstan 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 deployments
>
-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
>&
-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 h
>
> I think that starting 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).
t pivoting as a set-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 PostgreS
red me that we 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
xes
- --
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/punZgP
he future without needing to do a bump.
>
> In other words, +1 from me for going ahead and committing this for
> alpha2, if possible.
+1
- --
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVv52QAAoJEDfy9
-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 t
-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 wrote:
>> On 06/01/2015 02:21 AM, Dean Rasheed wrote:
>>> While going through this, I spotted another issue --- in a DML
>>> query
ons through measurement.
+1
I've been thinking along 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.
ypmod; we can deal 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-
-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
a qualified
> variable name (which I think is the only case that we'd have had
> any hope of supporting 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 .
of commit
> 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: GnuP
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/pushe
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:
http://ww
On 07/29/2015 01:26 PM, Robert Haas wrote:
> On Wed, Jul 29, 2015 at 3:58 PM, Alvaro Herrera
> 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 going to make an
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.
-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:
>
>
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(),
ou
are still having to calculate it, no?
- --
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVuPv8AAoJEDfy90M199hlYCwP/i0/berqnjXFch6zFM5TDZ6h
+UxQxMmVg933U6Cdoc+huMz8Hiotix76BZVgHOa8xI7Vktx1y5D7o7auczg31v4o
BkzbJFX9ziK5TXZm5wEvtTPNJOOq2
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.
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 inv
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 a/src/backend/commands/poli
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 InvokeObjectPostAlter
-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 ch
-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
>> a
lt type. The problem it's
>>> trying to solve is real, 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 suggest
-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
-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
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. Tes
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
) returns 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
k -- done
> 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?
- --
Jo
as if we change them as in my latest patch, the messages
will be different 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 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).
>>
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
passi
-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
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
-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
>> t
-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
> tags. The reference to BYPASSRLS also seems like it
> deserves markup, and p
On 07/22/2015 02:17 PM, Dean Rasheed wrote:
> On 21 July 2015 at 04:53, Michael Paquier wrote:
>> On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost wrote:
>>> We need to be careful to avoid the slippery slope of trying to prevent
>>> all covert channels, which has been extensively discussed previous
-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
> wrote:
>> On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway
>> wrote:
>>> On 06/08/2015 02:08 AM, Dean Rasheed wrote:
>>>> Actually
-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_col
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"));
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 through the
> security barrier view. The planner is then guaranteed to generate a
> TID scan,
uld win on
> terse.
The problem 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 n
-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
> wrote:
>> That explains why the first example works while the second does
>> not. I'm not sure how hard it would be to fix that,
201 - 300 of 1286 matches
Mail list logo
