Skip site navigation (1) Skip section navigation (2)

Re: Proposal: Store "timestamptz" of database creation on "pg_database"

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Date: 2013-01-03 08:16:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2013/1/3 Stephen Frost <sfrost(at)snowman(dot)net>:
> * Robert Haas (robertmhaas(at)gmail(dot)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


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


Pavel Stehule

>         Thanks,
>                 Stephen

In response to

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2013-01-03 10:03:17
Subject: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous:From: Pavel StehuleDate: 2013-01-03 07:55:03
Subject: Re: proposal: ANSI SQL 2011 syntax for named parameters

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group