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

On Thu, Apr 21, 2016 at 11:59 AM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> 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.
>
>
"Fear of both "unexpected drawbacks" and "perverse ​results" exist here."

And so far, NO ONE has shown any proof that this enhancement could possibly
cause ANY negative result.
All that has been presented so far are corner cases where this "might" not
be useful.
If the PostgreSQL developers are really worried about unexpected drawbacks,
then, based on that, ALL future development should stop immediately.
This is total insanity! I am asking for a simple, safe enhancement that
would add what compatibility with what is already in other databases, yet
everyone seems to be terrified about it.
We have already modified system catalogs previously with no ill effect.

So please, someone present a logical explanation of why this should not be
done, or how it will negatively impact the PostgreSQL project.
If you cannot do so, then start thinking positively.

Previous to yesterday, nowhere on the PostgreSQL site was it stated WHERE
to present enhancement requests.
Now that it has been verified this is the correct list, There still exists
no formal requirements for presenting an enhancement request.
WHY am I being vilified for making a simple request? How is it that
developers proceed with other enhancements, yet so much negative attention
is being given to my request because of unjustified fear that something bad
will happen?

Please, just ONE LOGICAL VALID argument, not speculation. Otherwise, stop
with the nay saying.

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.