Re: Removing pg_migrator limitations
От | Tom Lane |
---|---|
Тема | Re: Removing pg_migrator limitations |
Дата | |
Msg-id | 15594.1261186280@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Removing pg_migrator limitations (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Removing pg_migrator limitations
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > ... The idea I had was to create a global structure: > struct pg_migrator_oids { > Oid pg_type; > Oid pg_type_array; > ... > } > This would initialize to zero as a global structure, and only > pg_migrator server-side functions set it. I would prefer *not* to do that, as that makes the list of settable oids far more public than I would like; also you are totally dependent on pg_migrator and the backend to be in sync about the definition of that struct, which is going to be problematic in alpha releases in particular, since PG_VERSION isn't going to distinguish them. What I had in mind was more like static Oid next_pg_class_oid = InvalidOid; voidset_next_pg_class_oid(Oid oid){ next_pg_class_oid = oid;} in each module that needs to be able to accept a next-oid setting, and then the pg_migrator loadable module would expose SQL-callable wrappers for these functions. That way, any inconsistency shows up as a link error: function needed not present. regards, tom lane
В списке pgsql-hackers по дате отправления: