Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Hannu Krosing <hannu@2ndquadrant.com>
From: Hannu Krosing <hannu@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@2ndquadrant.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2013-01-03T16:15:31Z
Lists: 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