Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group