Re: [pgsql-patches] guid/uuid datatype

2007-01-26 Thread Peter Eisentraut
Jim Nasby wrote: Following that logic we should remove all data types that aren't specified in ANSI. Sure, if we were to arrive at some acceptable implementation of official modules, that would make sense in some cases. -- Peter Eisentraut http://developer.postgresql.org/~petere/

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Neil Conway
On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I'd be curious to know the degree to which the proposed patch is consistent with RFC 4122, which AFAIK is the most recent relevant standard. With regard to functions for generating

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Stefan Kaltenbrunner
Neil Conway wrote: On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I'd be curious to know the degree to which the proposed patch is consistent with RFC 4122, which AFAIK is the most recent relevant standard. With regard to

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Peter Eisentraut
Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do see that there needs to be

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Neil Conway
On Thu, 2007-01-25 at 17:57 +0100, Stefan Kaltenbrunner wrote: I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). I don't think distributing the (portable) generator

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Joshua D. Drake
Peter Eisentraut wrote: Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Bruce Momjian
Neil Conway wrote: On Thu, 2007-01-25 at 17:57 +0100, Stefan Kaltenbrunner wrote: I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). I don't think distributing the

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Joshua D. Drake
The MAC-based generator function could also be included in the backend, actually: it just needs to take an argument of type macaddr. It would then be up to the user (and/or various pgfoundry and contrib/ modules) to find a way to determine the local machine's MAC address, which presumably

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Gevik Babakhani
I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). This was my understanding too... to include the uuid in the core and let the actual value be generated

Re: [pgsql-patches] guid/uuid datatype

2007-01-25 Thread Jim Nasby
On Jan 25, 2007, at 11:13 AM, Peter Eisentraut wrote: I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do see that there needs to be some centrally organized

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client side. The uuid type is

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Magnus Hagander
Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
But does it really help if you don't have the generator? I don't use UUIDs much myself, but I think in all cases I've seen that use the uuid type in SQL Server they're also using the generator function. Those that just store UUIDs in the database often just uses varchar - in order to be

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Alvaro Herrera
Magnus Hagander wrote: Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote: Magnus Hagander wrote: Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Peter Eisentraut
Gevik Babakhani wrote: There could be many algorithms to generate a guid. I guess we will get into a big debate on that, which is not much useful i guess (seeing the posts last year). There are a handful of standardized or established algorithms, so it doesn't hurt to provide them all.

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Neil Conway
On Fri, 2007-01-19 at 23:00 -0500, Tom Lane wrote: Per previous discussion, the main problem with a uuid type is the new-uuid generator function, which tends to involve a bunch of not-so-portable assumptions and code. RFC 4122 specifies several ways of generating UUIDs: * via the computer's

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Neil Conway
On Sat, 2007-01-20 at 14:56 +0100, Gevik Babakhani wrote: what is the next step now? is there going to be review by a committer? if so, please note that the OIDs in the patch have to be changed. I already suggested a few things you could improve in the patch. If this discussion concludes that

Re: [pgsql-patches] guid/uuid datatype

2007-01-20 Thread Gevik Babakhani
I already suggested a few things you could improve in the patch. If this discussion concludes that the patch should be included in the core backend and you submit a revised patch, I'd be happy to review and apply it. So.. do we agree for uuid to be included in the core? If so.. I will change

[pgsql-patches] guid/uuid datatype

2007-01-19 Thread Gevik Babakhani
Hi, While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone have time to review it yet? Here it is again :) Regards, Gevik *** ./backend/utils/adt/Makefile.orig 2006-09-19 12:05:41.0 +0200 --- ./backend/utils/adt/Makefile 2006-09-19 12:06:47.0 +0200

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Neil Conway
On Fri, 2007-01-19 at 10:25 +0100, Gevik Babakhani wrote: While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone have time to review it yet? I confess I haven't followed the discussion around this patch, but is there a compelling reason to include this in the backend proper,

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Gevik Babakhani
I confess I haven't followed the discussion around this patch, but is there a compelling reason to include this in the backend proper, rather than contrib/? AFAIK, It is/was part of the TODO for the core. ---(end of broadcast)--- TIP 5: don't

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Neil Conway
On Sat, 2007-01-20 at 00:21 +0100, Gevik Babakhani wrote: AFAIK, It is/was part of the TODO for the core. Well, I don't have a strong opinion either way, but I think it should be given some thought. As far as the code, looks pretty good. A few minor comments: * varchar_uuid() should be named

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Bruce Momjian
Neil Conway wrote: On Sat, 2007-01-20 at 00:21 +0100, Gevik Babakhani wrote: AFAIK, It is/was part of the TODO for the core. Well, I don't have a strong opinion either way, but I think it should be given some thought. As far as the code, looks pretty good. A few minor comments: *

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Neil Conway
On Fri, 2007-01-19 at 19:19 -0500, Bruce Momjian wrote: I think having it in core makes the most sense. Why is that? One question that comes to mind is how the submitted patch compares in functionality to the other implementations of the UUID concept for PostgreSQL, such as OSSP uuid (which

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Peter Eisentraut
Bruce Momjian wrote: I should have been clearer. I think having in the main server or /contrib makes sense. Having data types external to our source tree doesn't seem to work too well because of changes in our API from time to time. When has the API for data types ever changed? -- Peter

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Bruce Momjian
Peter Eisentraut wrote: Bruce Momjian wrote: I should have been clearer. I think having in the main server or /contrib makes sense. Having data types external to our source tree doesn't seem to work too well because of changes in our API from time to time. When has the API for data

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: When has the API for data types ever changed? The API doesn't change, but the way to do things inside the type functions does changes sometimes. We've always done our best not to break user-defined datatypes without need. uuid

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Joshua D. Drake
Per previous discussion, the main problem with a uuid type is the new-uuid generator function, which tends to involve a bunch of not-so-portable assumptions and code. If we accept a uuid type in either core or contrib, all of a sudden those portability issues are our problem. I'd rather

Re: [pgsql-patches] guid/uuid datatype

2007-01-19 Thread Joshua D. Drake
Joshua D. Drake wrote: Per previous discussion, the main problem with a uuid type is the new-uuid generator function, which tends to involve a bunch of not-so-portable assumptions and code. If we accept a uuid type in either core or contrib, all of a sudden those portability issues are our