On Wed, Apr 20, 2016 at 5:14 PM, David G. Johnston < david.g.johns...@gmail.com> wrote:
> On Wed, Apr 20, 2016 at 1:50 PM, melvin6925 <melvin6...@gmail.com> wrote: > >> On Wed, Apr 20, 2016 at 12:59 PM, Melvin Davidson <melvin6...@gmail.com> >> wrote: >> >>> To Tom: >>> "it *sounds* trivial, until you start thinking about >>> backup/restore/replication situation" >>> >>> That is BS. It is trivial. >>> In backup/restore, there is no need to record the create date, as a new >>> create date is only needed if a table is dropped, otherwise if it exists on >>> restore it is a data restore only situation. If it is to create a new >>> database, then it is perfectly fine to use the new creation time. As for >>> replication, then it is a straightforward duplication of create time. >>> >>> To David: >>> "The burden seems to rest with you, not others. I'll leave it at that >>> since everything else has already been said elsewhere. >>> I'll add that failing to point out a previous discussion you were >>> involved with is inconsiderate to others reading these lists. " >>> >>> That is also a poor argument. My initial request was years ago and there >>> has never been a valid argument as to why this cannot be done. Please see >>> my response to Tom Lane. >>> Further to my point: >>> >>> http://stackoverflow.com/questions/4442323/how-to-find-out-when-a-particular-table-was-created-in-oracle >>> >>> http://stackoverflow.com/questions/1171019/sql-server-table-creation-date-query >>> both show proof that this has been implemented in those databases. >>> >>> So instead of replying back with "this has already been discussed and >>> cannot be done", I respectfully request that I get the courtesy of a >>> _detailed explanation_ of why this is appears so hard. It would also be >>> nice if you allowed a couple of days for other users to comment before so >>> rapidly dismissing it. Especially since we just went through a very length >>> discussion on code of conduct. >>> >>> > My response what simply that you brought this up again without any > reference to prior discussions or any apparent work toward making others > more likely to not only agree with you but to also perform the work. I > don't really have a position on the actual topic at hand - though I summed > my thoughts in great detail less than a year ago when you brought this up > last time: > > If your application needs to maintain knowledge of aging it should record > that information into user-space tables using whatever semantics it > requires. > > Courtesy goes both ways and given your bare-bones request it is not > surprising that I, and likely others, are choosing to respond "go look at > the previous discussions on this topic". Its not likely we care to rehash > our previous arguments in a new thread. > > >>> On Wed, Apr 20, 2016 at 2:58 PM, David G. Johnston < >>> david.g.johns...@gmail.com> wrote: >>> >>>> leaving off-list... >>>> >>>> On Wednesday, April 20, 2016, melvin6925 <melvin6...@gmail.com> wrote: >>>> >>>>> You are correct, nothing has changed. This is a very simple request >>>>> and should be easy to implement. I have yet to hear a valid, logical >>>>> argument against it. In fact. This has been implemented in both Oracle and >>>>> Sql Server. >>>>> >>>> >>>> The burden seems to rest with you, not others. I'll leave it at that >>>> since everything else has already been said elsewhere. >>>> >>>> I'll add that failing to point out a previous discussion you >>>> were involved with is inconsiderate to others reading these lists. >>>> >>>> I'll admit that maybe a better system for tracking and recording these >>>> kinds of requests would be nice - though expensive maintain - would be nice >>>> but in the meantime at least point to known history when bringing something >>>> like this up. At worse it shows you did your research. >>>> >>>> > I personally don't know whether it is worth whatever amount of effort it > would take to design, document, and implement this capability. If you want > a concrete explanation then I'd suggest putting forth an actual patch upon > which the -hackers can comment. It doesn't appear that anyone else on > -hackers is willing to put in the leg work for a feature they appear to > consider of marginal utility and in a line of work that they fear is likely > to result in even more requests of a similar nature that they, not the > people requesting, are apparently going to be on the hook for not only > maintaining but designing and coding as well. > > > What is it that you actually want from the community, and -hackers in > particular? An entry on the wiki TODO list? An entry in the "We don't > not want" section of the WIki TODO list? If all you want is to feel out > whether someone reading these lists is now willing to write such a patch > then for the most part it doesn't matter what or how many negative or > dubious responses you get - the possibility for commit is always open but > doesn't mean much until one person is willing to write a submit a patch. > > David J. > > > Really, it's that hard to add another column to an existing system catalog and document it? Hmm, let's try ALTER TABLE pg_catalog.pg_class ADD COLUMN relcreatedat timestamp default now(); Documentation Name Type References Descriptionrelcreatedat | timestamp | | The date and time the object was initially created Gee, that took over 4 minutes, I guess it is really is hard to do this... NOT. I do not have the capability of adding my own patch, but certainly is is not that hard to add one new column of type timestamp with a default of now() to the existing pg_class system catalog. I have already statedthe logic/reason/need behind it in my initial request, both today and years ago. as for Tom Lane saying that a forthcoming audit log will fulfill this request it is not completely true. An audit log will require additional code for reviewing, whereas a simple SQL query would be able to determine creation date if the column is added as requested, as per my previous support post on Oracle and SQL Server capability. As for what I want from the community, I would like other users and dba's to weigh in on this request and it's usefulness. -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
