Re: revised hstore patch

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> (b) many of the old names are significant collision risks.

Tom> What collision risks? PG does not allow loadable libraries to
Tom> export their symbols, so I don't see the problem. I recommend
Tom> just keeping those things named as they were.

You've never tested this, I can tell.

I specifically checked this point, back when working on the original
proposal (and when debugging the uuid code on freebsd, where uuid-ossp
crashes due to a symbol collision). If a loaded module compiled from
multiple source files defines some symbol, and another similar loaded
module tries to define the same symbol, then whichever one gets loaded
second will end up referring to the one from the first, obviously
causing hilarity to ensue.

I have a test case that demonstrates this and everything:

% bin/psql -c 'select foo()' postgres
NOTICE: mod1a foo() called
NOTICE: mod1b bar() called
foo
-----

(1 row)

% bin/psql -c 'select baz()' postgres
NOTICE: mod2a baz() called
NOTICE: mod2b bar() called
baz
-----

(1 row)

% bin/psql -c 'select baz(),foo()' postgres
NOTICE: mod2a baz() called
NOTICE: mod2b bar() called
NOTICE: mod1a foo() called
NOTICE: mod2b bar() called
baz | foo
-----+-----
|
(1 row)

% bin/psql -c 'select foo(),baz()' postgres
NOTICE: mod1a foo() called
NOTICE: mod1b bar() called
NOTICE: mod2a baz() called
NOTICE: mod1b bar() called
foo | baz
-----+-----
|
(1 row)

Notice that in the third case, foo() called the bar() function in mod2b,
not the one in mod1b which it called in the first case. All modules are
compiled with pgxs and no special options.

>> Certainly when developing this I had _SIGNIFICANT_ encouragement, some
>> of it from YOU, for increasing the limit.

Tom> Yes, but that was before the interest in in-place upgrade went up.
Tom> This patch is the first place where we have to decide whether we meant
Tom> it when we said we were going to pay more attention to that.

>> I'm prepared to give slightly more consideration to option #3: make
>> the new code read the old format as well as the new one.

Tom> If you think you can make that work, it would solve the problem.

OK. Should I produce an additional patch, or re-do the original one?

--
Andrew.