uuid_hash declaration

Started by Mel Flynnalmost 17 years ago5 messagesgeneral
Jump to latest
#1Mel Flynn
mel.flynn+pgsql@mailing.thruhere.net

Hi,

I'm trying to write a uuid extension using the FreeBSD libc uuid(3). I quickly
came to the conclusion it won't work, because:
/usr/include/uuid.h:54: error: conflicting types for 'uuid_hash'
../../src/include/utils/builtins.h:1010: error: previous declaration of
'uuid_hash' was here

Is there a way in the API to tell the backend that "uuid_hash function is
implemented by the foo__uuid_hash function" so that backwards compatibility
isn't broken?

There's 2 reasons I want this extension:
a) minimize external dependencies
b) conflict with e2fsprogs libuuid, required by my samba3 installation.

--
Mel

#2Dimitri Fontaine
dimitri@2ndQuadrant.fr
In reply to: Mel Flynn (#1)
Re: uuid_hash declaration

Mel Flynn <mel.flynn+pgsql@mailing.thruhere.net> writes:

Is there a way in the API to tell the backend that "uuid_hash function is
implemented by the foo__uuid_hash function" so that backwards compatibility
isn't broken?

Yes.
http://www.postgresql.org/docs/8.3/interactive/xfunc-c.html#XFUNC-C-PGXS

For example:

CREATE OR REPLACE FUNCTION uuid_hash(uuid)
RETURNS bool
AS 'MODULE_PATHNAME', my_uuid_hash
LANGUAGE 'C' IMMUTABLE STRICT;

Regards,
--
dim

#3Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Dimitri Fontaine (#2)
Re: uuid_hash declaration

Dimitri Fontaine wrote:

Mel Flynn <mel.flynn+pgsql@mailing.thruhere.net> writes:

Is there a way in the API to tell the backend that "uuid_hash function is
implemented by the foo__uuid_hash function" so that backwards compatibility
isn't broken?

Yes.
http://www.postgresql.org/docs/8.3/interactive/xfunc-c.html#XFUNC-C-PGXS

For example:

CREATE OR REPLACE FUNCTION uuid_hash(uuid)
RETURNS bool
AS 'MODULE_PATHNAME', my_uuid_hash
LANGUAGE 'C' IMMUTABLE STRICT;

I think the problem he is having is that we provide a C function named
uuid_hash, which conflicts with the one in FreeBSD's libc.

If that's the problem, my 2c is that uuid_hash is too generic a name to
export and we should change ours.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#3)
Re: uuid_hash declaration

Alvaro Herrera <alvherre@commandprompt.com> writes:

If that's the problem, my 2c is that uuid_hash is too generic a name to
export and we should change ours.

Too late for existing releases (since it would force initdb to fix the
pg_proc entry). We could change it in HEAD, but how much will that
really help?

regards, tom lane

#5Mel Flynn
mel.flynn+pgsql@mailing.thruhere.net
In reply to: Tom Lane (#4)
Re: uuid_hash declaration

On Monday 13 July 2009 06:54:54 Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

If that's the problem, my 2c is that uuid_hash is too generic a name to
export and we should change ours.

Too late for existing releases (since it would force initdb to fix the
pg_proc entry). We could change it in HEAD, but how much will that
really help?

Well, atm I'm looking for what should be in #else clause or elsewhere in the
code if I did something like:
#ifndef HAVE_UUID_BSD
extern Datum uuid_hash(PG_FUNCTION_ARGS);
#else
extern Datum uuid_hash2(PG_FUNCTION_ARGS);
#endif

that would still make the uuid_hash available in the SQL language. I'd be
happy to write some migration utilities, once I get more familiar with the
code. Right now, I'm just trying to make a drop-in replacement for the ossp-
uuid module.
--
Mel