Currently, I am running pg_dump on an entire table of a database by doing:
PGPASSWORD=$PGPASSWORDB /opt/data/PostgreSQL/9.4/bin/pg_dump -t RECORDER
-Fc $i -U pguser -Z0 | xz -9 > "$backup_dir/$i-$timeslot-database"
However, this table has a lot of rows.
Is there a way I could do pg_dump on a
On 12/17/2015 09:28 AM, anj patnaik wrote:
Currently, I am running pg_dump on an entire table of a database by doing:
PGPASSWORD=$PGPASSWORDB /opt/data/PostgreSQL/9.4/bin/pg_dump -t
RECORDER -Fc $i -U pguser -Z0 | xz -9 > "$backup_dir/$i-$timeslot-database"
However, this table has a lot of
And to get the structure of a table, you can use
pg_describe_object(catalog_id, object_id, object_sub_id)
On Fri, Dec 18, 2015 at 10:16 AM, Adrian Klaver
wrote:
> On 12/17/2015 09:28 AM, anj patnaik wrote:
>
>> Currently, I am running pg_dump on an entire table of a
Karl,
* Karl Czajkowski (kar...@isi.edu) wrote:
> Ideally, I'd be able to write a policy that has conditions for each
> category of operation:
>
>POLICY FOR SELECT WITH expr1
>POLICY FOR INSERT WITH expr2
>POLICY FOR DELETE WITH expr3
>POLICY FOR UPDATE WITH expr4
It's possible
Karl,
* Karl Czajkowski (kar...@isi.edu) wrote:
> 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
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