| From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Date created for tables |
| Date: | 2019-12-24 08:07:00 |
| Message-ID: | 4f3ff97f-8ffe-7cce-cf07-74fc21ab7e3c@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Ron schrieb am 24.12.2019 um 03:14:
>>> Having moved to PostgreSQL from Oracle a few years ago I have been generally
>>> very impressed by Postgres, but there are a few things that I still miss. One
>>> of those is being able to see the created and last modified dates for database
>>> objects.
>>>
>>> Is this something that has been considered for implementation?
>> I wrote a blog about this:
>>
>> https://momjian.us/main/blogs/pgblog/2017.html#November_21_2017
>
> You all are *grossly* over-complicating this.
>
> By creation time, "we DBAs" think the time we ran "CREATE object", not when pg_dump, pg_basebackup and pg_update ran.
>
> Likewise, modification time is when we last ran an ALTER command ran, not when VACUUM ran (that's tracked elsewhere) or DML ran.
>
> That's all.
+1
Although I don't really need this, there were a few situations where this came in handy in Oracle.
I think _any_ tracking would already help those people that need something like that.
Simply picking the easiest implementation and documenting the situations where those columns are updated would probably be enough.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | M Tarkeshwar Rao | 2019-12-24 10:32:10 | Postgres cursor taking 2 hrs to update the table |
| Previous Message | Scott Ribe | 2019-12-24 03:15:02 | logical replication protocol |