On Fri, Jan 4, 2013 at 4:07 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 1/3/13 3:26 PM, Robert Haas wrote: > It's true, as we've often > said here, that leveraging the OS facilities means that we get the > benefit of improving OS facilities "for free" - but it also means that > we never exceed what the OS facilities are able to provide.
And that should be the deciding factor, shouldn't it? Clearly, the OS timestamps do not satisfy the requirements of tracking database object creation times.
+1
And IMHO we must decide what we do or if we'll don't anything.
In this thread was discussed many ways to how to implement and how not implement, so I compile some important points discussed before (sorry if I forgot something):
* the original proposal was just to add a column in shared catalog 'pg_database' to track creation time (I already sent a patch [1]), but the discussion going to implement a way to track creation time off all database objects
* some people said if we implement that then we must have some way to alter creation times by SQL (ALTER cmds) and also have a way to dump and restore this info by pg_dump/pg_restore. Some agreed and others disagree.
* we talk about implement it with EventTriggers, but they not cover shared objects (like databases, roles, tablespaces,...), and someone talked to extend EventTriggers to cover this kind of objects or maybe we have a way to create *shared tables* (this is what I understood). This way force to every people implement your own track time system or maybe someone share a extension to do that.
* also we discuss about create two new catalogs, one local and another shared (like pg_description and pg_shdescription) to track creation times of all database objects.
Please fix if I forgot something. Anyway, we must decide what to do.
I don't know enough, but I have another idea. What you guys think about we have tables like "stats tables" to track creation times, with a GUC to enable or disable this behavior.
