I've been trying to learn more about the row-security policies but
coming up short in my searches. Was there any consideration to
allowing access to both old and new row tuples in a POLICY ... CHECK
expression? This idiom I've seen in the lower level rule and trigger
systems seems like it would
On Dec 16, Stephen Frost modulated:
> There is still a need to refer back to some kind of state that is
> external to the table under consideration to determine what the session
> level access is, no? Even if the ACLs are in a table somewhere, how do
> you know who the current user is?
>
Yes,
I feel that the fundamental question here is about the semantics of
"row" in row security. The core question is whether UPDATE has a
different semantics with respect to row identity and security context
than a sequence of DELETE, INSERT.
At the moment, the documented solution feels like "tuple
On Dec 18, Stephen Frost modulated:
> I agree that it would be a nice addition, as I've said before.
OK, sorry I misunderstood earlier and thought you were dismissing the
idea as redundant with triggers. Thanks for your patience!
> ... We certainly won't be adding it into 9.5 and it's getting
On Dec 18, Stephen Frost modulated:
> Any UPDATE which requires SELECT rights on the table will require expr1
> to pass AND expr4 (the UPDATE's USING clause) to pass. This is modeled
> directly off of our existing GRANT/ACL system. The same is true for the
> other commands. Note that we
Hi, has there been any discussion as to supporting row-level security
policies on materialized views? I didn't have much luck searching on
this topic. I see that PostgreSQL 9.5 refuses to create a policy on
a materialized view, consistent with the documentation focusing only on
tables.
First
On Apr 27, Tim van der Linden modulated:
...
> I'm joining three fairly large tables together, and it is slow. The tables
> are:
>
> - "reports": 6 million rows
> - "report_drugs": 20 million rows
> - "report_adverses": 20 million rows
>
...
> All tables have indexes on the "id"/"rid" columns
On Apr 20, Tom Lane modulated:
> Karl Czajkowski <kar...@isi.edu> writes:
> > CREATE POLICY delete_stuff ON stuff
> > FOR DELETE USING ('example attribute value' = ANY ( ((SELECT
> > current_attributes()))::text[] ));
>
> Just out of curiosity, why are you d
Our row level policies require very explicit casts in order to be
accepted by the DB, but those casts are discarded in the dumped policy
statements. Thus, an attempt to reload the dump file fails. I'm not
sure if the underlying problem is that the cast shouldn't be required
in the first place, or
On May 09, Sterpu Victor modulated:
> I tested it now, EXPLAIN ANALYZE is not showing LEFT JOIN at all if
> I don't select from the joined tables.
> Now is clear why the query is so mutch more efficient when I select
> less data.
>
> Thank you
>
With so many joins, you may want to experiment
On Jul 08, John McKown modulated:
...
> I think the "problem" that he is having is fixable only by changing how
> PostgreSQL itself works. His problem is a PL/pgSQL function which is
> 11K lines in length. When invoked, this function is "compiled" into a
> large tokenized parse tree. This parse
On Sep 10, Tim Uckun modulated:
> I am trying to get the child elements of a one to many table to be
> rolled up into a json field in the parent table. The query I am running
> is...
The problem is aggregating over the results of the left-outer join,
which introduces NULLs. You can try pushing
On Oct 27, Karl Czajkowski modulated:
> Hi, I am struggling to find information on how the new parallel query
> features intersect with row-level security. I am wondering whether
> this is expected to work at this time?
>
Further experimentation shows that I can get parallel pl
Hi, I am struggling to find information on how the new parallel query
features intersect with row-level security. I am wondering whether
this is expected to work at this time?
My cursory experiments indicate that we can get a parallel plan when
querying as the table owner or superuser but not
Hi,
Is there a formal definition for the order in which constraint actions
(i.e. the ON DELETE or ON UPDATE rules) are applied when there are
multiple overlapping/relevant constraints?
I have struggled to find an answer in the manual, but my experiments
suggest that they are interpreted in the
On Nov 08, David G. Johnston modulated:
...
> ON DELETE starts with the "one" side of a one-to-many relationship.
> When deleting the one row the question is what should be done with the
> many rows which refer to it. If ALL of the many rows agree to be
> deleted then the one row in question
I can relate to the original plea from my own exploration of this
topic.
Before I get into that, I will mention as an aside that to date we
have found RLS to be really slow for web client authorization, given
that we have to use session parameters to store web client context and
there doesn't
On Jan 14, Tomas Vondra modulated:
...
> Sure, a lot of systems generate queries on the fly. Also, if the
> main problem is poor plan choice due to RLS, I'm not sure how
> prepared statements could help with that.
>
Sorry for being unclear, I was trying to respond to too many
sub-topics at once.
I believe that in its fully glory, you cannot reliably locate CSV
record boundaries except by parsing each field in order including
quote processing. Individual records may have arbitrary numbers of
field and record separator characters within the values.
Karl
On Mar 08, Rob Sargent modulated:
On Mar 08, John McKown modulated:
...
> I agree. I went with a "pure BASH" approach because it is what the
> user asked for & I wasn't sure what language she might be comfortable
> with. I use PERL a lot. Or maybe I should say that I abuse PERL a lot.
> Such as a PERL script with writes out
On Mar 08, Rob Sargent modulated:
> Yes Karl, I agree. I admitted as much. But if it's clean, as in
> free of quoted commas, life is much more simple. I've lost site of
> whether or not the OP knows his situation w.r.t. to this. The awk
> line will tell him and for a one-off load this can
> Select currval('GEN_')
>
>From the above, I am assuming you did something like:
CREATE SEQUENCE "GEN_" ...;
and are trying to access this sequence? If so, you actually have to
include the SQL quoted identifier syntax within the text argument to
currval() or nextval(), e.g.
SELECT
On May 31, armand pirvu modulated:
> The idea is that I would like to avoid having an index for each key
> possibly wanted to search, but rather say have the whole record then
> search by the key and get the key value, thus having one index serving
> multiple purposes so to speak
>
First,
On Jun 01, armand pirvu modulated:
> Overall could it be that the optimizer blatantly ignores a scan index which
> is cheaper than a table scan, or jsonb implementation still has a long way to
> come up or the way it is used in my case is not the one designed for ?
>
If I remember correctly,
On Sep 14, vinny modulated:
> If it is only one database, on one server, then couldn't you just
> use one sequence?
> If oyu prefix the value with some identifier of the current table
> then you cannot get duplicates
> across tables even if you reset the sequence.
>
I didn't follow the whole
On Sep 14, Rafal Pietrak modulated:
> My main objective is the "guarantee". Which I've tried to indicate
> referring to "future UPDATEs".
>
With a well-behaved application, it is sufficient to define each
ID column as:
id int8 UNIQUE NOT NULL DEFAULT nextval('sharedsequence')
and ensure
26 matches
Mail list logo
