Re: Temporal extensions
От | Dave Jones |
---|---|
Тема | Re: Temporal extensions |
Дата | |
Msg-id | 553EC17D.2090407@waveform.org.uk обсуждение исходный текст |
Ответ на | Re: Temporal extensions (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Temporal extensions
|
Список | pgsql-hackers |
Hi Jim, On 27/04/15 21:48, Jim Nasby wrote: > On 4/25/15 7:49 PM, Dave Jones wrote: >> I've been working on a conversion of several utilities I wrote for >> another engine, and was wondering if there was any interest in seeing >> any of them added to contrib/ at some point in the vague undefined >> future? > > Not in contrib, no, because there's no reason for these to be tied to > specific versions of Postgres. Adding to PGXN would make sense though. Thanks for the reply and suggestion - I've just run across PGXN having finished reading through the all the temporal-related e-mails I could find on pgsql-hackers for the last 5 years or so (specifically, Jeff Davis' temporal extension). PGXN looks like a good place to park this (once I've sorted out a few of the things I've run across while reading - TRUNCATE triggers for it for starters!). > (Though, I dislike using timestamps to do change/history tracking, but > that's just me...) I've been playing around with history tracking (in the context of BI, typically with batch loaded reporting databases) for about 7-8 years now and always found timestamps perfect for the purpose, but are you perhaps referring to using it for audit purposes? If that's the case I'd agree entirely - this is absolutely the wrong tool for such things (which is something I need to put a bit more prominently in the docs - it's buried in the design section at the moment). Or did you mean ranges would be better? They certainly looked intriguing when I started moving this stuff to postgres, and I'd like to re-visit them in the near future as they offer capabilities I don't have with timestamps (such as guaranteeing no overlapping ranges via exclusion constraints) but my initial tests suggested some rather major performance degradation so I put it on the back-burner at first. Thanks, Dave.
В списке pgsql-hackers по дате отправления: