Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
От | Hannu Krosing |
---|---|
Тема | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
Дата | |
Msg-id | 50E56CBF.5040409@krosing.net обсуждение исходный текст |
Ответ на | Re: Proposal: Store "timestamptz" of database creation on "pg_database" (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Re: Proposal: Store "timestamptz" of database creation
on "pg_database"
Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
Список | pgsql-hackers |
On 01/03/2013 11:18 AM, Andres Freund wrote: > On 2013-01-03 11:03:17 +0100, Hannu Krosing wrote: >> On 12/28/2012 03:14 AM, Stephen Frost wrote: >> ... >>> I agree that what I was suggesting would be possible to implement with >>> event triggers, but I see that as a rather advanced feature that most >>> users aren't going to understand or implement. At the same time, those >>> more novice users are likely to be looking for this kind of information- >>> being told "oh, well, you *could* have been collecting it all along if you >>> knew about event triggers" isn't a particularly satisfying answer. That's >>> my 2c on it. I agree that having the example in the docs would be nice- >>> examples are always good things to include. >> If what you want is something close to current unix file time semantics >> (ctime, mtime, atime) then why not just create a function to look up these >> attributes on database directory and/or database files ? > Because too many things change those. Moving to a different tablespace, > a rewriting ALTER TABLE, etc. Can't we actually fix these to preserve file creation date like tar does and still keep unix file semantics ? So it is as about agreeing on what we actually want this "create time" mean opening a can of worms as tom predicted ? For example, how would this work in replication context ? > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > >
В списке pgsql-hackers по дате отправления: