Re: Removing pg_migrator limitations

Greg Stark <gsstark(at)mit(dot)edu> writes:
> 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.

The problem is that we *don't* want a nice abstract interface. We want
one that lets us specify the exact OIDs to use for the enum values.
Which is about as non-abstract as you can get.

regards, tom lane