2013/1/3 Stephen Frost <sfr...@snowman.net>: > * Robert Haas (robertmh...@gmail.com) wrote: >> Well, IMHO, there is no need for any syntax change at all. CREATE >> TABLE and CREATE DATABASE should just record the creation time >> somewhere, and that's all. If you dump-and-reload, the creation time >> changes. Deal with it, or hack your catalogs if you really care that >> much. > > I'd be alright with this also, tbh. Not preserving such information > across pg_dump's wouldn't really be all *that* much of a loss. > > As for hacking at the catalogs, I do find that a rather terrible > recommendation, ever. I'm currently trying to convince people at $work > that hacking at pg_database to modify datallowconns is really not a > good or ideal solution (and requires a lot more people to have > superuser rights than really should, which is practically no one, imo). > Annoyingly, we don't seem to have a way to ALTER DATABASE to set that > value, although I *think* 'connection limit = 0' might be good enough. > >> I find the suggestion of using event triggers for this to miss the >> point almost completely. At least in my case, the time when you >> really wish you had some timestamps is when you get dropped into a >> customer environment and need to do forensics. The customer will not >> have installed the convenient package of event triggers at database >> bootstrap time. Their environment will likely be poorly configured >> and completely undocumented; that's why you're doing forensics, isn't >> it? > > Exactly, that's what I was trying to get at upstream. > >> I know this has been discussed and rejected before, but I find that >> rejection to be wrong-headed. I have repeatedly been asked, with >> levels of exasperation ranging from mild to homicidal, why we don't >> have this feature, and I have no good answer. If it were somehow >> difficult to record this or likely to produce a lot of overhead, that >> would be one thing. But it isn't. It's probably a hundred-line >> patch, and AFAICS the overhead would be miniscule. > > +1
+1 yes, this task can be simply solved by EVENT TRIGGERS, but native implementation can carry some unification - and time of creation is basic attribute that I would to see everywhere. And I am not alone regards Pavel Stehule > > Thanks, > > Stephen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
