On Tue, Apr 26, 2011 at 5:33 PM, Rose Nancy <rnancy at afilias.info> wrote:
> Hi,
>
> Thank you for your quick reply.
> The problem with changing these to type 'text' with alter table is that,
> amongst my list of table using the data type "name",
> I have "_oxrsaero.vactables.relname" which is a COMPOSITE TYPE and according
> to the Postgres 8.3 documentation I cannot ALTER the attributes of a
> COMPOSITE TYPE.
>
> Also I don't think that DROP and RECREATE  "_oxrsaero.vactables.relname "
> will be a good idea since some Slony functions might be using it.
>
> So any idea...

Oh, it's certainly there in order to be used.  I'm pretty sure I'm "at
fault" for its addition, and if it were *not* referenced, it would be
pretty fair to get rid of it.  :-)

That type is used as the structure to indicate tables that are to be
vacuumed by the cleanup thread.

It should be a pretty reasonable idea to drop the type and recreate it
with a more suitable definition.  That wouldn't disturb Slony terribly
much, as it's only a slon process that would access it, and it seems
likely to me that having a slon running during the pg_upgrade process
would be TOTALLY disastrous!  :-)  I'm pretty sure slons will be down
at that time!

Look for the definition in the sources in
src/backend/slony1_base.v*.sql; it's actually reasonably
well-documented there.

You'd presumably also need to drop the function TablesToVacuum(), and
recreate that.

I am a bit undecided as to the merits of making such a change.  As
Andrew observed, the "name" type is intended to be used for system
datatypes; Slony tends to behave in a pretty 'system-y' way, so it's
not totally "out there" for it to be using "name".  But if it's a
relatively minor "tweak" to have Slony use text in lieu of "name" and
play better with pg_upgrade, well, there's some value to that.

Seeing as how nobody has really tried to think through the
implications of the change, it's not obvious that this is something we
ought to be doing in any already existing branch of Slony.  I'd not be
too keen to "quickly shove it through" on 2.0, or even the
hopefully-forthcoming-in-not-too-long 2.1.