On Mon, Apr 13, 2009 at 2:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> this my proposal is very simple. It help to people who have to manage >> large or complex database system. Important data are date of creating >> and date of altering tables and stored procedures. These data cannot >> be modified by user, so implementation doesn't need any new >> statements. > > ISTM anyone who thinks they need this actually need a full DDL log; > or at least, if we give them this, they will be back next week asking > for a full log. So it'd save a lot of work to tell them to just log > their DDL to start with.
DDL logs are good, but you generally can't keep them around forever, so it's helpful to have some basic information that occupies O(1) space. So based on that I'd respond to these objections as follows: > Some obvious objections to the simple approach: > - what if I want to know *who* made the change Fine, let's log the OID of the creator and of the person who made the last change, too (or else decide that the dependency problems are too thorny - we'd need to set this to NULL if a role is dropped - and don't). > - what if I need to know about the change before last Tough, you should have a DDL log. > - what if I need to know about a DROP Tough, you should have a DDL log. > - what if I need to know about operators, operator classes, schemas, etc > etc Fine, let's log this info for those too (or else decide they're too obscure and don't - pg_class and pg_proc are certainly the most interesting cases). In my applications, these requirements comes up frequently for user data and I've handled it by adding creation_time, creator_id, last_updated_time, last_updater_id columns to nearly every table that users can modify. It satisfies 90% of the auditing requirements for 10% of the work, and there's nothing to say that a more elaborate mechanism can't be built and used where necessary (which I have also done - but only for particularly critical data). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
