Re: contrib function naming, and upgrade issues

>>>>> "Simon" == Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:

> On Sat, 2009-03-21 at 01:57 +0000, Andrew Gierth wrote:
>> Note that I'm talking here about the names of the C functions, not
>> the SQL names.
>>
>> The existing hstore has some very dubious choices of function names
>> (for non-static functions) in the C code; functions like each(),
>> delete(), fetchval(), defined(), tconvert(), etc. which all look to me
>> like prime candidates for name collisions and consequent hilarity.
>>
>> The patch I'm working on could include fixes for this; but there's an
>> obvious impact on anyone upgrading from an earlier version... is it
>> worth it?

Simon> Perhaps you can have two sets of functions, yet just one .so?
Simon> One with the old naming for compatibility, and a set of
Simon> dehilarified function names for future use. Two .sql files,
Simon> giving the user choice.

Two .sql files would be pointless. Remember we're talking about the C
function names, not the SQL names; the only time the user should notice
the difference is when restoring an old dump.

As I see it there are three options:

1) do nothing; keep the existing C function names. dump/restore from
older versions will still work, but new functionality won't be
available without messing with the SQL.

2) hard cutover; rename all the dubious C functions. dump/restore from
older versions will get lots of errors, for which the workaround will
be "install the new hstore.sql into the database before trying to
restore".

3) some sort of compatibility hack involving optionally duplicating the
names in the C module.

--
Andrew.