On Thu, Jun 29, 2006 at 06:47:17PM +0200, Martijn van Oosterhout wrote:
> It seems to me that maybe the backend should include a 16-byte fixed
> length object (after all, we've got 1, 2, 4 and 8 bytes already) and
> then people can use that to build whatever they like, using domains,
> for example...

Sooooo... Back to this.

It won't happen unless somebody does it - and I realize that people
are busy with their own projects, so unless somebody more willing and
better suited will step up, I'm going to take a stab at getting
advanced consensus.

Please answer the below questions, and state whether your opinion is
just an opinion, or whether you are stating it as a PostgreSQL
maintainer and it is law. If you wish, you can rank preferences.

1) The added 128-bit type should take the form of:

    a) UUID, with all functions
    b) UUID, with only basic generation functions + encode/decode/indexable
    c) UUID, with only encode/decode/indexable - generic except for the
       name of the type, and the encoding format.
    d) Generic 128-bit type - same as c) except may not encode or decode
       as UUID (dashes). Either a large number (hex string?), or binary data.
    e) Generic n-byte binary data type generator. Not sure of feasibility
       of this at this point. See thread.

2) According to your answer in 1), the added 128-bit type should be:

    a) In core first.
    b) In contrib first.
    c) In pgfoundry first.


.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to