Thread: uuid_hash declaration

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

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

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.

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

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