On 19/10/2010 10:12 PM, Mauricio Chamati wrote:
> I am recomming
to you guys to have an special "Section" for Audit tables. As we
separate sequence in another seq, we should do the same for Audit
tables. They have their own behavior, are less used, and so on.
As a senior software architect, you should know how to write clearer
descriptions of what you want :-P
Your suggestion is really broad. It's not clear exactly what you are
suggesting or what you actually want, or even what kind of audit tables
you're referring to.
Are you suggesting that there should also be a facility to put some
tables outside the normal transactional flow, so that writes to them are
retained when a transaction rolls back? (If so: this can be done, albeit
hackishly, with dblink).
Are you suggesting support for audit logging of SELECTs? ie "ON SELECT"
triggers or some similar mechanism?
Do you want separate storage and/or WAL logging of audit tables for
performance reasons? If Pg ever supports separate WAL logging for
different databases or different sets of tables, that'd be an attractive
option for audit tables. As it is, you already can use tablespaces to
put them on different storage.
Do you want built-in support for marking tables/columns as "audited" so
the database system automatically manages recording of audit data to
audit tables with no need to define triggers etc?
If not, what exactly is it that you *do* want?
Now, personally, if we're talking "database innovation" what I'd like to
see is a built-in way to get query results straight from the database as
graphs of tuples and their relationships. Tabular result sets are poorly
suited to some kinds of workloads, including a few increasingly common
ones like document-oriented storage and use via ORMs. In particular, the
way ORMs tend to do multiple LEFT OUTER JOINs and deduplicate the
results or do multiple queries and post-process to form a graph is
wasteful and slow. If Pg had a way to output an object graph (or at
least tree) natively as, say, JSON, that'd be a marvellous option for
some kinds of workloads, and might help the NoSQL folks from whining
quite so much as well ;-)
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
