From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_migrator issue with contrib |
Date: | 2009-06-08 18:49:05 |
Message-ID: | 1624.1244486945@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jun 8, 2009 at 1:32 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> You mean like PG_MODULE_MAGIC?
> Hey, how about that. Why doesn't that solve our problem here?
> [ thinks ... ] I guess it's because there's no guarantee that the
> function is installed on the SQL level with the signature that is
> appropriate on the C level.
Yeah. And it's more than just the function itself. For example,
in the contrib/isn mess, the function definitions didn't change.
The problem is the passbyval flag (or lack of it) on the type
definition.
I think we've speculated in the past about having ways of embedding
per-function data into the .so libraries so that these sorts of
things could be caught automatically. But it'd be a lot of work
for rather limited reward.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-06-08 18:56:18 | Re: pg_migrator issue with contrib |
Previous Message | Tom Lane | 2009-06-08 18:39:01 | Re: pg_migrator issue with contrib |