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.
Thanks,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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...
http://mark.mielke.cc/
---------------------------(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
match
