Proposal for GUID datatype - Mailing list pgsql-hackers

From Gevik Babakhani
Subject Proposal for GUID datatype
Date
Msg-id 1157743100.21979.37.camel@voyager.truesoftware.net
Whole thread Raw
Responses Re: Proposal for GUID datatype  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposal for GUID datatype  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Proposal for GUID datatype  (Jan de Visser <jdevisser@digitalfairway.com>)
Re: Proposal for GUID datatype  (Markus Schaber <schabi@logix-tt.com>)
List 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


  



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fixed length data types issue
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Fix linking of OpenLDAP libraries