Re: revised hstore patch

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> (b) many of the old names are significant collision risks.
Tom> What collision risks?  PG does not allow loadable libraries toTom> export their symbols, so I don't see the
problem. I recommendTom> 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() calledfoo 
-----
(1 row)

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

% bin/psql -c 'select baz(),foo()' postgres
NOTICE:  mod2a baz() called
NOTICE:  mod2b bar() called
NOTICE:  mod1a foo() called
NOTICE:  mod2b bar() calledbaz | 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() calledfoo | 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
todecide whether we meantTom> 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
thenew 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.