Proposal for GUID datatype

From: Gevik Babakhani <pgdev(at)xs4all(dot)nl>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Proposal for GUID datatype
Date: 2006-09-08 19:18:20
Message-ID: 1157743100.21979.37.camel@voyager.truesoftware.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Folks,

I would like to submit the following proposal regarding the
implementation of the GUID datatype. Based on the findings, thoughts and
the discussion we have had in the past, I am going to propose the
following:

1) Datatype name would be "uuid" or "guid".
example: create table tbl (fld uuid, fld2 ....);

2) Accepted input/output datatype and formats:

The input/output datatype would be string(36)

2a) Three input formats are supported.
example:
insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
insert into tbl (fld) values('1dfb39afb56a40b8a903b5b31567c3ce');

2b) Only one default output format is supported.
example:

# select fld from tbl;

fld
--------------------------------------+
1dfb39af-b56a-40b8-a903-b5b31567c3ce |

2b.a) An additional function will be available to provide other
output formats or an existing function like to_char will support the
additional formatting options.

3) Internal datatype
Because there is not going to be any kind of (mathematically meaningful)
calculation on the guid values, the internal datatype would be just a
simple 16 byte unsigned char (uint8). This would help when comparing
these values and can also be compressed inline

Proposed data structure would be:

typedef struct uuid_t {
char data[16];
} uuid_t;

4) Comparing functions and operators

The default comparing functions and operators like
= < != > etc, etc.. would be implemented as required.
Note that guid >= guid would not mean anything. The values will
internally be compared as strings.

5) support functions:
because uuid could also be used as PK or unique values, additional
function(s) will be available to produce a uuid value to be used in
a field's default value like sequences or PL/pgSQL etc.. etc...

example;

create table tbl(
ID uuid default ('new_uuid()'),
....
);

5.a) If needed an additional macro-type like SERIAL could also
be developed in later stage.

6) pg_type layout:

typname = uuid
typnamespace = pg_catalog
typowner = (default) // db owner
typlen = 16
typbyval = FALSE // type is byref
typtype = b // built-in type
typisdefiled = true
typdelim = ',' // ',' seperator for array of uuid
typrelid = 0
typelem = 0
typinput = to be defined later
typoutput = to be defined later
typreceive = not supported
typsend = not supported
typanalyze = 0 // default analyze
typalign = c
typstorage = m // stored compressed inline
typnotnull = false // can be null

other pg_type attributes are set to default values.

Please send your comments and suggestions to complete or modify this
proposal.

Regards,
Gevik

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-08 19:20:00 Re: [HACKERS] Fix linking of OpenLDAP libraries
Previous Message Bruce Momjian 2006-09-08 19:15:18 Re: Fixed length data types issue