Re: RPMS for 7.3 beta.

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> I have a basic build running, but it's not releasable. I haven't had time to
> go through it with the properly fine-toothed comb that I want to as yet. I
> would expect to be able to release an RPMset for beta 2 if that is a week or
> two off.

Sounds good. I think the earliest we could be ready for beta2 is the
end of this week; sometime next week may be more realistic.

Given that we'll be forcing an initdb for beta2 anyway, those who use
RPMs may be just as happy to have missed beta1.

> I am waiting the result of the pg_dump from 7.2.x to 7.3 restore discussion.

Right. We clearly have to support loading of 7.2 dumps; the only issue
in my mind is exactly how we kluge that up ;-). I just talked to Bruce
about this a little bit, and we came to the conclusion that there are
two plausible-looking paths:

1. Relax CREATE LANGUAGE to accept either LANGUAGE_HANDLER or OPAQUE as
the datatype of the function (ie, make it work more like CREATE TRIGGER
does).

2. Hack CREATE LANGUAGE so that if it's pointed at an OPAQUE-returning
function, it actually updates the recorded return type of the function
in pg_proc to say LANGUAGE_HANDLER.

If we go with #1 we're more or less admitting that we have to support
OPAQUE forever, I think. If we go with #2, then dumps out of 7.3 or
later would be OPAQUE-free, and we could eventually remove OPAQUE a few
release cycles down the road. So even though #2 looks mighty ugly,
I am leaning in that direction.

Whichever way we jump, I think the same behavior should be adopted for
all three contexts where OPAQUE is relevant: language handlers,
triggers, and user-defined-datatype I/O functions. Either we accept
OPAQUE forever, or we proactively fix the function declarations when
an old dump is loaded.

Another interesting thought is that if we do the OPAQUE-to-HANDLER
update thing, we could at the same time coerce the stored path for
the PL's shared library into the preferred '$libdir/foo' format,
rather than the absolute-path form it's likely to have if we're dealing
with a pre-7.2 dump. This would not help anything immediately (if you
got past the CREATE FUNCTION then you gave a valid shlib path) but it'd
very possibly save people trouble down the road.

Comments?

regards, tom lane