WHY PostgreSQL have not a simple and reliable method to access table creation time? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

As showed by vage answers of the question PostgreSQL: Table creation time and similar questions, there are no simple way to get creation time of a table... Tasks for control, table administration or table audit (as well as cache systems and other ones) need this important information... So, WHY PostgreSQL not offer a simple and direct way to get it? Can not use a internal system table or a compile flag to create this field (at pg_class for example)?

Answer 1

PostgreSQL is a community-driven open source project. Development is by a mixture of interested volunteers, consultants paid to work on their customers' problems, and companies that sell PostgreSQL services who want to make PostgreSQL more attractive to users.

If nobody who wants the feature is willing to pay for its development, spend the time to develop the patch themselves, or pressure a company they use services from to develop it, it won't get developed.

Unless you're a prospective user who's likely to want to sign on for support / services, or can convince somebody that your need is shared by a large user base, it's not likely you'll convince someone to spend their own paid commercial developer time on it.

This is a "put up or ..." kind of situation.

As it happens I'm thinking about adding this as part of the EU AXLE project for PostgreSQL security and audit that I'm involved in. I have other pressing priorities first, though, so it won't be coming from me for quite some time.

Most people land up wanting the last-modified time, not just the created time. That's a lot harder because it forces a metadata write for every commit. Pg can't just use the on-disk modification time because (a) it has multiple extents for each table, and (b) non-user activity like VACUUM and hint-bit setting still writes to the table. It is not my intention to tackle that, and so far I haven't seen anybody who wants it who is also willing to do the work to make it happen.

(I've marked this "Community Wiki" since it's not really Q&A, and I'm close-voting this question).

Answer 2

A main reason is simple - we (PostgreSQL developers) doesn't find a agreement how to implement this feature (and what this feature should to do). Now, after years of discussion there is simple solution available - every body can use "EVENT TRIGGERS" (PostgreSQL 9.3) and can implement this functionality how it needs.