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
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 |