Re: contrib/snapshot

From: Joel Jacobson <joel(at)gluefinance(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/snapshot
Date: 2011-01-03 09:15:34
Message-ID: AANLkTik_aCpFqCcQT9PgBHAmKDjDe5VEuLStQVJ6erNo@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/1/3 Andrew Dunstan <andrew(at)dunslane(dot)net>

> "contrib" in PostgreSQL means "a module maintained by the backend
> developers".
>
But it's not clear to me that there is any particular reason why this should
> be in contrib.
>

Then I definitively think contrib is the only possible place for this
module.
If the module will not be maintained by the backend developers, noone
(including myself) will trust the module to perform the sensistive tasks in
a mission critical production database.
Since the module depends on pg_catalog system tables, it's must be updated
if the they would change in future versions of PostgreSQL, and I wouldn't
trust any other team than the backend developers to do it.

I'm happy to continue hacking on the module until it's 100% working,
stable, thoroughly tested and accepted by the backend developers.
It's not working 100% yet, for instance, I'm currently working on making
sure objects are created/dropped in an order not breaking any dependencies.

--
Best regards,

Joel Jacobson
Glue Finance

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-01-03 09:37:56 Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Previous Message Magnus Hagander 2011-01-03 09:03:36 Re: Recovery conflict monitoring