On Tue, Sep 09, 2008 at 10:50:57PM -0400, Robert Haas wrote:
> > When people aren't keeping track of their DDL, that is very
> > strictly a process problem on their end. When people are shooting
> > themselves in the foot, it's a great disservice to market Kevlar
> > shoes to them.
>
> I can't be
Hi,
On Tue, 2008-09-09 at 23:14 -0400, Andrew Dunstan wrote:
> Nothing is cost free. Every feature adds to code complexity, and has
> to be maintained.
With full respect to you: I'm only talking about creation time. How much
overhead and complexity are you expecting?
Cheers,
--
Devrim GÜNDÜZ, R
Hannu Krosing wrote:
> Timestamps should rather be considered a forensic tool.
>
> You may have the best VCS system, but if somebody bypasses it, you may
> still need to find out, when it was done.
So you're arguing for modification time, which is not was Devrim is
proposing -- he's proposing cr
On Wed, 2008-09-10 at 09:27 +0300, Volkan YAZICI wrote:
> On Tue, 9 Sep 2008, David Fetter <[EMAIL PROTECTED]> writes:
> >> AFAICS, PostgreSQL is not keeping info about when a table, database,
> >> sequence, etc was created. We cannot get that info even from OS,
> >> since CLUSTER or VACUUM FULL m
Hi,
Devrim GÜNDÜZ wrote:
On Tue, 2008-09-09 at 15:36 -0400, Tom Lane wrote:
why would creation time (as opposed to any other time, eg last schema
modification, last data modification, yadda yadda) be especially
significant?
Hmm, those would be cool, too.
maybe except last data modification.
On Tue, 9 Sep 2008, David Fetter <[EMAIL PROTECTED]> writes:
>> AFAICS, PostgreSQL is not keeping info about when a table, database,
>> sequence, etc was created. We cannot get that info even from OS,
>> since CLUSTER or VACUUM FULL may change the metadata of
>> corresponding relfilenode.
>
> When
Robert Haas wrote:
I try pretty hard not to shoot myself in the foot. But if someone
comes up to me and offers me some shoes that are have the same cost,
appearance, comfort-level, and durability as regular shoes but are
slightly more bullet resistant, should I refuse them on principle?
Why?
> When people aren't keeping track of their DDL, that is very strictly a
> process problem on their end. When people are shooting themselves in
> the foot, it's a great disservice to market Kevlar shoes to them.
I can't believe anyone is going to stop tracking their DDL because,
ooh goody, now we
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 t
On Tue, Sep 09, 2008 at 10:20:00PM +0300, Devrim GUNDUZ wrote:
> Hi,
>
> AFAICS, PostgreSQL is not keeping info about when a table, database,
> sequence, etc was created. We cannot get that info even from OS,
> since CLUSTER or VACUUM FULL may change the metadata of
> corresponding relfilenode.
Hi Andrew,
On Tue, 2008-09-09 at 16:22 -0400, Andrew Dunstan wrote:
> I'd like to know why logging statements won't do the trick here.
It is not on by default, logs are rotated, and may be lost, etc.
Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.o
daveg wrote:
On Tue, Sep 09, 2008 at 11:03:56PM +0300, Hannu Krosing wrote:
On Tue, 2008-09-09 at 12:40 -0700, daveg wrote:
I'd be very interested in seeing a last schema modification time for pg_class
objects. I don't care about it being preserved over dump and restore as my
use cas
On Tue, Sep 09, 2008 at 11:03:56PM +0300, Hannu Krosing wrote:
> On Tue, 2008-09-09 at 12:40 -0700, daveg wrote:
>
> > I'd be very interested in seeing a last schema modification time for
> > pg_class
> > objects. I don't care about it being preserved over dump and restore as my
> > use case is m
On Tue, 2008-09-09 at 12:40 -0700, daveg wrote:
> I'd be very interested in seeing a last schema modification time for pg_class
> objects. I don't care about it being preserved over dump and restore as my
> use case is more to find out when a table was created with a view to finding
> out if it is
> There isn't sufficient support for such a "feature".
It sounds like a useful feature to me.
> In any case, why
> would creation time (as opposed to any other time, eg last schema
> modification, last data modification, yadda yadda) be especially
> significant?
Those would be nice to have too,
On Tue, 2008-09-09 at 15:36 -0400, Tom Lane wrote:
> why would creation time (as opposed to any other time, eg last schema
> modification, last data modification, yadda yadda) be especially
> significant?
Hmm, those would be cool, too.
Seriously, I believe we can get last data modification from
On Tue, Sep 09, 2008 at 03:36:19PM -0400, Tom Lane wrote:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> > AFAICS, PostgreSQL is not keeping info about when a table, database,
> > sequence, etc was created. We cannot get that info even from OS, since
> > CLUSTER or VACUUM FULL m
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> AFAICS, PostgreSQL is not keeping info about when a table, database,
> sequence, etc was created. We cannot get that info even from OS, since
> CLUSTER or VACUUM FULL may change the metadata of corresponding
> relfilenode.
> Does any
Hi,
AFAICS, PostgreSQL is not keeping info about when a table, database,
sequence, etc was created. We cannot get that info even from OS, since
CLUSTER or VACUUM FULL may change the metadata of corresponding
relfilenode.
Does anyone think that adding a timestamp column to pg_class would bring
an
19 matches
Mail list logo
