Re: contrib function naming, and upgrade issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-21 04:38:01
Message-ID: 14879.1237610281@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> 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?

I agree that this wasn't an amazingly good choice, but I think there's
no real risk of name collisions because fmgr only searches for such names
within the particular .so. As you say, renaming *will* break existing
dumps. I'd be inclined to leave it alone, at least for now. I hope
that someone will step up and implement a decent module system for us
sometime soon, which might fix the upgrade problem for changes of this
sort.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-03-21 05:44:00 Re: BUG #4721: All sub-tables incorrectly included in search plan for partitioned table
Previous Message Bruce Momjian 2009-03-21 03:59:35 Re: small but useful patches for text search