Re: [pgsql-patches] guid/uuid datatype
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
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 UUIDs, I think we should at least include the methods specified by RFC 4122 that can be implemented without too many unportable assumptions. I believe that means MD5 SHA1 hashing of an arbitrary identifier, and UUIDs generated via a PSRNG. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] guid/uuid datatype
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 functions for generating UUIDs, I think we should at least include the methods specified by RFC 4122 that can be implemented without too many unportable assumptions. I believe that means MD5 SHA1 hashing of an arbitrary identifier, and UUIDs generated via a PSRNG. 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/). Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] guid/uuid datatype
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 some centrally organized consolidation of the various existing attempts under a label of officiality. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
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 functions separately makes a lot of sense. For the generation methods that just depend on md5() or random(), we may as well include them in the backend if we're going to include the rest of the UUID stuff. 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 can't be done reliably in a portable fashion. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
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 see that there needs to be some centrally organized consolidation of the various existing attempts under a label of officiality. I think it would be more important to determine how we can get UUID in core. It is a known and accepted way of doing things in the marketplace and professional communities. It is time we stop fighting features for the sake of fighting features. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
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 (portable) generator functions separately makes a lot of sense. For the generation methods that just depend on md5() or random(), we may as well include them in the backend if we're going to include the rest of the UUID stuff. 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 can't be done reliably in a portable fashion. I assume we could just allow the MAC address or some unique idenfier to be specified in postgesql.conf. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
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 can't be done reliably in a portable fashion. I assume we could just allow the MAC address or some unique idenfier to be specified in postgesql.conf. Well at that point why don't we allow it to be specified per database? ALTER DATABASE foo SET uuid_salt = :) That would be pretty cool, but I am sure most will shoot that down in flames :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
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 elsewhere...(client or separate project)... I do not think having a uuid datatype as contrib module separately will do us much good. All professional dbs support this as built in. So why shouldn't we... Regards, Gevik. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
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 consolidation of the various existing attempts under a label of officiality. Following that logic we should remove all data types that aren't specified in ANSI. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
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 very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). Regards, Gevik. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
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 side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). 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 more portable, I guess. Not saying it wouldn't be good to have uuid for portability, I'm just a bit unsure of how much use it is without a generator function... //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
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 more portable, I guess. 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). In most cases I have seen the guid is generated by the client. In case of M$ Sql is also can be generated on the server but, in our case we generate the guids ourselves because with our algorithm we can trace the guid back to where it exactly was originated. (app requirement) One thing is for sure, having varchar to store guids ( varchar(32) ) is not that efficient. Regards, Gevik. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] guid/uuid datatype
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 then going to be on the client side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). But does it really help if you don't have the generator? We could have all the type code in core, and the generator in contrib or pgfoundry. That way the user can choose the most appropriate generator, even if it's platform-specific. Or he can choose to use a client-side generator. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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
Re: [pgsql-patches] guid/uuid datatype
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 of the uuid is then going to be on the client side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). But does it really help if you don't have the generator? We could have all the type code in core, and the generator in contrib or pgfoundry. That way the user can choose the most appropriate generator, even if it's platform-specific. Or he can choose to use a client-side generator. that seems like a good compromise - have the type in core and generators in contrib/pgfoundry. In one or two releases we might see some feedback on the portability and how people use those and could decide on leaving it that way or move the generators into core as well. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] guid/uuid datatype
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. Compare pgcrypto -- certainly no one needs all those encryption algorithms, but we offer them. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
Re: [pgsql-patches] guid/uuid datatype
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 MAC address and the time since the Gregorian epoch in nanoseconds * via MD5 or SHA1 hashing of a given string of URL, or similar identifier * via a PSRNG Only the first of these presents any portability concerns, AFAICS. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] guid/uuid datatype
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 the patch should be included in the core backend and you submit a revised patch, I'd be happy to review and apply it. -Neil ---(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
Re: [pgsql-patches] guid/uuid datatype
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 the assigned OIDs in the patch to match the current source-tree and update the code with the suggestions provided by Neil. Are we okay on this? Regards, Gevik. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[pgsql-patches] guid/uuid datatype
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 *** *** 15,21 endif endif ! OBJS = acl.o arrayfuncs.o array_userfuncs.o arrayutils.o bool.o \ cash.o char.o date.o datetime.o datum.o domains.o \ float.o format_type.o \ geo_ops.o geo_selfuncs.o int.o int8.o like.o lockfuncs.o \ --- 15,21 endif endif ! OBJS = uuid.o acl.o arrayfuncs.o array_userfuncs.o arrayutils.o bool.o \ cash.o char.o date.o datetime.o datum.o domains.o \ float.o format_type.o \ geo_ops.o geo_selfuncs.o int.o int8.o like.o lockfuncs.o \ *** ./include/catalog/pg_amop.h.orig 2006-09-19 12:05:39.0 +0200 --- ./include/catalog/pg_amop.h 2006-09-19 12:06:47.0 +0200 *** *** 594,599 --- 594,601 DATA(insert ( 2232 0 1 f 2334 )); /* aclitem_ops */ DATA(insert ( 2235 0 1 f 974 )); + /* uuid */ + DATA(insert ( 2868 0 1 f 2866 )); /* * gist box_ops *** *** 886,889 --- 888,898 DATA(insert ( 2780 0 3 t 2752 )); DATA(insert ( 2780 0 4 t 1070 )); + /* btree uuid */ + DATA(insert ( 2873 0 1 f 2869 )); + DATA(insert ( 2873 0 2 f 2871 )); + DATA(insert ( 2873 0 3 f 2866 )); + DATA(insert ( 2873 0 4 f 2872)); + DATA(insert ( 2873 0 5 f 2870 )); + #endif /* PG_AMOP_H */ *** ./include/catalog/pg_amproc.h.orig 2006-09-19 12:05:39.0 +0200 --- ./include/catalog/pg_amproc.h 2006-09-19 12:06:47.0 +0200 *** *** 125,130 --- 125,132 DATA(insert ( 2233 0 1 380 )); DATA(insert ( 2234 0 1 381 )); DATA(insert ( 27890 1 2794 )); + /*uuid*/ + DATA(insert ( 28730 1 2863 )); /* hash */ *** *** 161,166 --- 163,171 DATA(insert ( 2231 0 1 456 )); DATA(insert ( 2232 0 1 455 )); DATA(insert ( 2235 0 1 329 )); + /* uuid */ + DATA(insert ( 2868 0 1 2874 )); + /* gist */ *** ./include/catalog/pg_cast.h.orig 2006-09-19 12:05:39.0 +0200 --- ./include/catalog/pg_cast.h 2006-09-19 12:06:47.0 +0200 *** *** 196,201 --- 196,206 /* Cross-category casts between int4 and char */ DATA(insert ( 18 23 77 e )); DATA(insert ( 23 18 78 e )); + /* uuid */ + DATA(insert ( 25 2854 2876 a )); + DATA(insert ( 2854 25 2877 a )); + DATA(insert ( 1043 2854 2878 a )); + DATA(insert ( 2854 1043 2879 a )); /* * Datetime category *** ./include/catalog/pg_opclass.h.orig 2006-09-19 12:05:39.0 +0200 --- ./include/catalog/pg_opclass.h 2006-09-19 12:06:47.0 +0200 *** *** 208,211 --- 208,216 DATA(insert OID = 2779 ( 2742 _reltime_ops PGNSP PGUID 1024 t 703 )); DATA(insert OID = 2780 ( 2742 _tinterval_ops PGNSP PGUID 1025 t 704 )); + /* uuid */ + DATA(insert OID = 2873 ( 403 uuid_ops PGNSP PGUID 2854 t 0 )); + DATA(insert OID = 2868 ( 405 uuid_ops PGNSP PGUID 2854 t 0 )); + + #endif /* PG_OPCLASS_H */ *** ./include/catalog/pg_operator.h.orig 2006-09-19 12:05:39.0 +0200 --- ./include/catalog/pg_operator.h 2006-09-19 12:06:47.0 +0200 *** *** 883,888 --- 883,898 DATA(insert OID = 2751 ( @ PGNSP PGUID b f 2277 2277 16 2752 0 0 0 0 0 arraycontains contsel contjoinsel )); DATA(insert OID = 2752 ( ~ PGNSP PGUID b f 2277 2277 16 2751 0 0 0 0 0 arraycontained contsel contjoinsel )); + /* uuid operators */ + + DATA(insert OID = 2866 ( = PGNSP PGUID b t 2854 2854 16 2866 2867 2869 2869 2869 2870 uuid_eq eqsel eqjoinsel )); + DATA(insert OID = 2867 ( PGNSP PGUID b f 2854 2854 16 2867 2866 0 000uuid_ne neqsel neqjoinsel )); + DATA(insert OID = 2869 ( PGNSP PGUID b f 2854 2854 16 2870 2872 0 0 0 0uuid_lt scalarltsel scalarltjoinsel )); + DATA(insert OID = 2870 ( PGNSP PGUID b f 2854 2854 16 2869 2871 0 0 00uuid_gt scalargtsel scalargtjoinsel )); + DATA(insert OID = 2871 ( = PGNSP PGUID b f 2854 2854 16 2872 2870 0 0 0 0uuid_le scalarltsel scalarltjoinsel )); + DATA(insert OID = 2872 ( = PGNSP PGUID b f 2854 2854 16 2871 2869 0 0 0 0uuid_ge scalargtsel scalargtjoinsel )); + + /* * function prototypes *** ./include/catalog/pg_proc.h.orig 2006-09-19 12:05:39.0 +0200 --- ./include/catalog/pg_proc.h 2006-09-19 12:37:38.0 +0200 *** *** 3940,3945 --- 3940,3980 DATA(insert OID = 2749 ( arraycontained PGNSP PGUID 12 f f t f i 2 16 2277 2277 _null_ _null_ _null_ arraycontained - _null_ )); DESCR(anyarray contained); + /* uuid */ + DATA(insert OID = 2855 ( uuid_inPGNSP PGUID 12 f f t f i 1 2854 2275 _null_ _null_ _null_ uuid_in - _null_ )); + DESCR(I/O); + DATA(insert OID = 2856 ( uuid_out PGNSP PGUID 12 f f t f i 1 2275 2854
Re: [pgsql-patches] guid/uuid datatype
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, rather than contrib/? -Neil ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
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 forget to increase your free space map settings
Re: [pgsql-patches] guid/uuid datatype
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 uuid_varchar(), for consistency with the other function names. In fact, uuid_text() and varchar_uuid() are essentially identical, so they should be refactored. The fmgr interface macros can stay, I guess. * most of uuid.h can be gotten rid of: the SQL-callable functions are already declared in builtins.h, and most of the other declarations should be moved to uuid.c and made local to that file. * needs documentation -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] guid/uuid datatype
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: * varchar_uuid() should be named uuid_varchar(), for consistency with the other function names. In fact, uuid_text() and varchar_uuid() are essentially identical, so they should be refactored. The fmgr interface macros can stay, I guess. * most of uuid.h can be gotten rid of: the SQL-callable functions are already declared in builtins.h, and most of the other declarations should be moved to uuid.c and made local to that file. * needs documentation I think having it in core makes the most sense. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] guid/uuid datatype
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 implements a Postgres UDT in its CVS version), or the UUID project on gborg. -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
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 Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
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 types ever changed? The API doesn't change, but the way to do things inside the type functions does changes sometimes. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] guid/uuid datatype
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 doesn't seem to need any hooks into the core system that would make it any more likely to break than anything else. 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 not deal with that. I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] guid/uuid datatype
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 not deal with that. I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? I think it would. There are plenty of client side libraries that generate uuid, at least we could provide a native type for them to use. A generator would be great too of course, but if they really need one they could use one of the pl languages for it. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
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 problem. I'd rather not deal with that. I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? I think it would. There are plenty of client side libraries that generate uuid, at least we could provide a native type for them to use. A generator would be great too of course, but if they really need one they could use one of the pl languages for it. As a follow up to this both Java and Python have uuid generators that are built in. Which as we all know are both extremely portable languages. Sincerely, Joshua D. Drake Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
