| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Subject: | Re: Removing pg_migrator limitations |
| Date: | 2009-12-23 21:23:44 |
| Message-ID: | 407d949e0912231323v464f212dicc13ca0282a3f914@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 23, 2009 at 8:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-12-23 21:26:47 | Re: what about _PG_fini |
| Previous Message | Cédric Villemain | 2009-12-23 21:17:03 | what about _PG_fini |