Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

On Thu, Apr 21, 2016 at 8:18 AM, Melvin Davidson <melvin6925(at)gmail(dot)com>
wrote:

> On Thu, Apr 21, 2016 at 11:08 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> > wrote:
>
>> On 04/21/2016 07:53 AM, Melvin Davidson wrote:
>>
>>
>>> "Whether that is worthy or not is the point of your request and really
>>> depends on more input."
>>> Correct. And that is what I am looking for. Stating obscure corner cases
>>> does not rule out the need for an enhancement. If it did, there would be
>>> no point in any enhancement.
>>> As of yet, other than this will not work for certain cases, I have not
>>> heard any argument where this would cause harm to the PostgreSQL
>>> database (performance or security concern)
>>> or that this will take any great effort to implement, as I have already
>>> disproved that in a previous update.
>>>
>>
>> Making OIDs a default column on user tables was probably not a great
>> effort either. Easy and all user tables got a built in PK, until folks
>> started pushing more data into their database and the OID counter wrapped
>> which had consequences for both user and system tables. Just saying I would
>> want to hear more from the folks that deal with the internals.
>>
>>
> And your point is? Adding an nullable column with a default of now() to a
> system catalog has no impact whatsoever on OID's.
> Please state a relevant case how this negatively impacts anything.
> ​
>

​Y​
our grasp of analogy
​ could use some work...

That was a long winded way of saying that there is this thing called
"unintended consequences".​

​https://en.wikipedia.org/wiki/Unintended_consequences

Fear of both "unexpected drawbacks" and "perverse ​results" exist here.

David J.