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

On Wed, Jan 2, 2013 at 9:12 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> If I believed that it would be a hundred-line patch, and would *stay*
>> a hundred-line patch, I'd be fine with it. But it won't. I will
>> bet a very fine dinner that the feature wouldn't get out the door
>> before there would be demands for pg_dump support.
>
> Fine, how about a function that can be called by pg_dump (and anyone
> else who has the rights and feels the need) to set that value? That
> avoids all need for any new syntax and still gives us the pg_dump and
> friends support that will apparently be asked for.

TBH, I don't think anyone has any business changing the creation
timestamp. Ever. For me, the fact that pg_dump wouldn't preserve
this information would be a feature, not a bug. I mostly meant to
point out that someone could bypass it if they cared enough, not to
recommend it. Honestly, I'd probably *rather* store this information
someplace where it couldn't be changed via SQL *at all*. But I don't
think we have such a place, so I'm happy enough to store it in the
catalogs, with the associated risks of catalog hackery that entails.

>> And arguments
>> about whether ALTER should or should not change the timestamp.
>
> There is no case where ALTER should change the *creation* time, imo.

Duh.

>> And I doubt you counted psql \d support in that hundred lines.
>> So this is just a can of worms that I'd rather not open.
>
> The last psql \d support change that I looked at (thanks Jon) had a
> diffstat (excluding documentation and whitespace changes) of:
>
> sfrost(at)beorn:/home/sfrost/Downloads> cat qq | diffstat
> describe.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> Just saying. ;)

Yeah, I don't think this is really a problem. I would expect the psql
support for this feature to be not a whole lot more complicated than
that. Sure, it might be more than 5 lines of raw code if it requires
an additional version of some query for which we're currently using
the same version for both PG93 and PG92, but it's hardly fair to cite
that as an argument for not doing this. Such changes are almost
entirely boilerplate.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company