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 | 50E5AEA3.4070002@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: Proposal: Store "timestamptz" of database creation
on "pg_database"
|
Список | pgsql-hackers |
On 01/03/2013 03:09 PM, Robert Haas wrote: > On Thu, Jan 3, 2013 at 8:46 AM, Hannu Krosing <hannu@2ndquadrant.com> wrote: >> How is "what does database creation date mean?" a different question ? >> >> It is same question as : >> >> what is the creation date of db when I create a replica of my database from >> backup? >> >> does it depend on how I restore my replica ? >> >> can I restore it from pg_dump and still have same creation date ? >> >> etc. etc. ... > Of course, these objections miss the point. Even an imperfect > solution will be better than no solution at all. And it is very > likely that if we simply provide whatever hydrating agent lies closest > to hand, we'll get full marks. This is what I did with my sample pl/python function ;) > Similarly, in the present situation, I believe that there is little > reason to suppose that the simplest possible implementation of this > feature won't resolve the overwhelming majority of the needs that > people have. We have many features about which users might raise the > same kinds of questions that you are raising about this one, and they > do, and those questions are perfectly valid. But they are not reasons > to remove those features, and the questions you raise are not reasons > to avoid having this one. They are simply things that must be > documented and explained, just as we need to do with every other > feature we ship. And if someone is not perfectly happy with the > design, it won't be the first time for that, either. It does not mean > that it's worse than not having anything. > If we made sure that things like CLUSTER or moving to another tablespace would keep file ctime, then this would answer 98% of requests . Even without keeping them, this would be giving the chap "water" ... So my proposal is to just have a pg_database_createtime(dbname) function and solve the simple part of the problem. ----------------- Hannu
В списке pgsql-hackers по дате отправления: