Re: Determining when a row was inserted - Mailing list pgsql-general

From Alex Turner
Subject Re: Determining when a row was inserted
Date
Msg-id 33c6269f05060312363ff334df@mail.gmail.com
Whole thread Raw
In response to Re: Determining when a row was inserted  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
I really wasn't suggesting it be put in the table structure at the DB level, more a sidebar suggestion for people building schemas for companies.  I can't count the number of times I've been asked when something was inserted and we didn't have an answer for the question.  Wouldn't it be nice for a change to be _ahead_ of the game?

Alex Turner
netEconomist

On 6/3/05, Martijn van Oosterhout <kleptog@svana.org> wrote:
> On 6/3/05, Wiebe de Jong <wiebedj@shaw.ca> wrote:
> >
> > The way I do it is to add a timestamp field with a default value of now().
> > Unfortunately, this won't help with any records that have already been
> > created.
On Fri, Jun 03, 2005 at 02:40:08PM -0400, Alex Turner wrote:
> One might even suggest that this should really be a default for all tables
> everywhere, because at some time or another, someone wants to know when
> something got put in the database...

Except it's still a complete waste of space for most tables. People
have been arguing for years that OIDs are a waste of space and now
they've been made optional and will soon default to off. There's not
likely to be support to add another field in it's place.

Just like timetravel was removed from the core given that most people
don't need it and it's prohibitive in diskspace usage. If you want it,
enable it yourself.

Have a nice day.
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Preventing Multiple Inheritance
Next
From: Philip Hallstrom
Date:
Subject: Re: Limits of SQL