From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, 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-24 22:40:52 |
Message-ID: | 22739.1261694452@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> The reason I don't want to do it that way is that then you need two
>> ugly kluges in the backend, not just one. With the zero-and-add-one
>> approach there is no need to have a "next enum oid" variable at all.
> Uh, I still need that variable because that is how we are going to set
> the oid in EnumValuesCreate(), unless we want to add dummy oid-value
> arguments to that function for use only by the binary upgrade
> server-side function.
Please go back and re-read what I suggested: you need a function along
the lines of
add_enum_member(enum-type, 'value name', value-oid)
and then there's no need for any saved state. So what if it has a
different signature from the other pg_migrator special functions?
It's not doing the same thing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-12-24 22:53:11 | Re: Removing pg_migrator limitations |
Previous Message | Bruce Momjian | 2009-12-24 22:34:43 | Re: Removing pg_migrator limitations |