Re: Removing pg_migrator limitations - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Removing pg_migrator limitations
Date
Msg-id 407d949e0912231323v464f212dicc13ca0282a3f914@mail.gmail.com
Whole thread Raw
In response to Re: Removing pg_migrator limitations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing pg_migrator limitations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 23, 2009 at 8:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If we're going to implement something whose ambitions only extend to
> satisfying pg_migrator's needs, then it should be a specialized
> pg_migrator function.

Fwiw my feeling was the opposite here. It's better to offer even
limited SQL-level support for features pg_migrator needs because the
more abstract and loosely coupled the interface is between pg_migrator
and the internals the better. Even if the interface is somewhat
limited and just good enough for pg_migrator's needs it's still easier
to support a well-defined abstract interface than one that depends on
knowing about the internal implementation.

I can see I'm outvoted here though and you and Bruce are the ones
writing the code so far...

-- 
greg


pgsql-hackers by date:

Previous
From: Cédric Villemain
Date:
Subject: what about _PG_fini
Next
From: Tom Lane
Date:
Subject: Re: what about _PG_fini