On Thu, Apr 21, 2016 at 8:18 AM, Melvin Davidson <melvin6...@gmail.com> wrote:
> On Thu, Apr 21, 2016 at 11:08 AM, Adrian Klaver <adrian.kla...@aklaver.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.
