From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | fabriziomello(at)gmail(dot)com, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgaudit - an auditing extension for PostgreSQL |
Date: | 2014-10-08 03:36:49 |
Message-ID: | 5434B151.9090406@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/07/2014 09:44 AM, Fabrízio de Royes Mello wrote:
> We can think in a mechanism to create "properties / options" and assign it
> to objects (table, index, column, schema, ...) like COMMENT does.
>
> A quickly thought:
>
> CREATE OPTION [ IF NOT EXISTS ] name
> VALIDATOR valfunction
> [ DEFAULT value ];
>
> ALTER TABLE name
> SET OPTION optname { TO | = } { value | 'value' | DEFAULT };
>
> It's just a simple thought of course. We must think better about the syntax
> and purposes.
If we're going to do this (and it seems like a good idea), we really,
really, really need to include some general system views which expose
the options in a user-friendly format (like columns, JSON or an array).
It's already very hard for users to get information about what
reloptions have been set.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2014-10-08 03:41:46 | Re: pgaudit - an auditing extension for PostgreSQL |
Previous Message | Alvaro Herrera | 2014-10-08 03:05:39 | Re: pg_dump refactor patch to remove global variables |