Re: Proposal: Store "timestamptz" of database creation on "pg_database"
От | Pavel Stehule |
---|---|
Тема | Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
Дата | |
Msg-id | CAFj8pRD=Hv=6RWcF1n+TreA9XVF_GGv2D+fgFZMKL07qAjMfKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Store "timestamptz" of database creation on "pg_database" (Hannu Krosing <hannu@krosing.net>) |
Список | pgsql-hackers |
2013/1/3 Hannu Krosing <hannu@krosing.net>: > 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 ? Implementation of ctime, mtime, atime will have little bit higher impact than just creation time - and these values should be moved to statistics instead bloated pg_class. You cannot use a filesystem data, because some requests are solved by cache not by filesystem. I had to emulate MySQL fields - and this was a first implementation, but totally useles - now we have a solution based on enhancing pg_stat and it works as expected Regards Pavel > > ---------------- > Hannu > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: