Skip site navigation (1) Skip section navigation (2)

Re: Removing pg_migrator limitations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: 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-19 01:31:20
Message-ID: 15594.1261186280@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)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;

	void
	set_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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-12-19 01:32:45
Subject: pgsql: Allow read only connections during recovery, known as Hot
Previous:From: Joe ConwayDate: 2009-12-19 01:27:06
Subject: Re: Removing pg_migrator limitations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group