Andrew Dunstan wrote:
<...>
> 
> Can someone please give a good, concrete use case for this stuff? "Might 
> be nice to have" doesn't cut it, I'm afraid. In particular, I'd like to 
> know why logging statements won't do the trick here.
> 

Please pardon the kibbitzer intrusion ... 

Informix has this feature and I've often yearned for it in PostgreSQL (although 
it is low on my personal priorities). Typical use case I've run into is working 
on legacy databases where the original DBA is gone or senile (deprecating 
self-reference not to applied to any one on this list) and I need to make sense 
of a muddle of similarly named tables or functions with the same structure but 
different row counts or variant codings. The logs have long since been offlined 
to gosh knows where or lost -- we're talking 5 or more years of activity -- and 
even scripts may be suspect (the checked in script might refer to an original 
table but the DBA made on the fly changes) or some other DBA-like creature did 
things without proper procedures being followed.

Having that date has been critical to resolving those issues of which table 
came in which order. It also gives a time window to use to go check old emails, 
archives, etc. for more information. 

Last update of data seems prohibitively expensive; if a user wants that a 
trigger and a 2nd table could well do that. Last DDL mod ... I could see the 
use but my old workhorse doesn't offer it so it never occurred to me to want 
it. Until know. '-)

But this request is adding metadata, I agree. But with my vague understandings 
adding a date or time stamp for table creation wouldn't be a large bloat and if 
only required at creation seems low overhead. 

But maybe only bad DBAs need it. Or good DBAs who inherit systems from bad ones 
?

Sorry for the crufty posting -- my web client has recently deteriorated in 
terms of message formatting.

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information and must be protected in accordance with those 
provisions. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)

Reply via email to