Re: [HACKERS] Opinion about macro for the uuid datatype.
Am Sonntag, 17. September 2006 01:47 schrieb Gevik Babakhani: The development of the uuid datatype is yet in progress... I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. Could you do this using a domain? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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: [HACKERS] Opinion about macro for the uuid datatype.
On Mon, 2006-09-18 at 13:20 +0200, Peter Eisentraut wrote: Am Sonntag, 17. September 2006 01:47 schrieb Gevik Babakhani: The development of the uuid datatype is yet in progress... I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. Could you do this using a domain? Tom had a very good point about this. So developing a SERIAL like thing for the uuid is something that we are going to see the need in the future. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Opinion about macro for the uuid datatype.
Am Montag, 18. September 2006 13:28 schrieb Gevik Babakhani: Could you do this using a domain? Tom had a very good point about this. And that point was? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Opinion about macro for the uuid datatype.
It was Gevik Babakhani [EMAIL PROTECTED] writes: I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. This assumes a fact not in evidence, which is that we're going to accept a uuid-generation function as part of core. AFAIK the only reasonably non-contentious part of this proposal is the ability to *store* uuids. Generating new ones introduces a host of portability and other issues. Considering the amount of pain involved in supporting SERIAL in the parser, pg_dump, etc, I'd say that adding the above is a pretty certain route to getting your patch rejected as too invasive. If, three or four versions down the road, large numbers of people are using uuid with the same generation function, *then* it might be time to think about introducing a macro type. regards, tom lane On Mon, 2006-09-18 at 13:47 +0200, Peter Eisentraut wrote: Am Montag, 18. September 2006 13:28 schrieb Gevik Babakhani: Could you do this using a domain? Tom had a very good point about this. And that point was? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Opinion about macro for the uuid datatype.
Am Montag, 18. September 2006 13:50 schrieb Gevik Babakhani: It was My question was, Could you do this using a domain?. The possible answers to that are Yes and No, neither of which appears below, nor does domain. Gevik Babakhani [EMAIL PROTECTED] writes: I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. This assumes a fact not in evidence, which is that we're going to accept a uuid-generation function as part of core. AFAIK the only reasonably non-contentious part of this proposal is the ability to *store* uuids. Generating new ones introduces a host of portability and other issues. Considering the amount of pain involved in supporting SERIAL in the parser, pg_dump, etc, I'd say that adding the above is a pretty certain route to getting your patch rejected as too invasive. If, three or four versions down the road, large numbers of people are using uuid with the same generation function, *then* it might be time to think about introducing a macro type. regards, tom lane On Mon, 2006-09-18 at 13:47 +0200, Peter Eisentraut wrote: Am Montag, 18. September 2006 13:28 schrieb Gevik Babakhani: Could you do this using a domain? Tom had a very good point about this. And that point was? -- 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: [HACKERS] Opinion about macro for the uuid datatype.
On Mon, 2006-09-18 at 14:23 +0200, Peter Eisentraut wrote: Am Montag, 18. September 2006 13:50 schrieb Gevik Babakhani: It was My question was, Could you do this using a domain?. The possible answers to that are Yes and No, neither of which appears below, nor does domain. I don't know could have been also a possible answer ;) But yes, It is perfectly possible to do that using a domain: something like: CREATE DOMAIN SERIAL_GUID uuid DEFAULT new_guid(); Regards, Gevik. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Opinion about macro for the uuid datatype.
Understood, Thank you :) On Sat, 2006-09-16 at 21:23 -0400, Tom Lane wrote: Gevik Babakhani [EMAIL PROTECTED] writes: I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. This assumes a fact not in evidence, which is that we're going to accept a uuid-generation function as part of core. AFAIK the only reasonably non-contentious part of this proposal is the ability to *store* uuids. Generating new ones introduces a host of portability and other issues. Considering the amount of pain involved in supporting SERIAL in the parser, pg_dump, etc, I'd say that adding the above is a pretty certain route to getting your patch rejected as too invasive. If, three or four versions down the road, large numbers of people are using uuid with the same generation function, *then* it might be time to think about introducing a macro type. 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
[HACKERS] Opinion about macro for the uuid datatype.
The development of the uuid datatype is yet in progress... I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. something like: create table tbl ( mypk SERIALGUID; ) which creates create table tbl ( mypk uuid default new_guid(); ) or do you think this would be an overkill? regards, Gevik. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Opinion about macro for the uuid datatype.
Gevik Babakhani [EMAIL PROTECTED] writes: I was wondering if I should go ahead and add a macro datatype like the SERIAL, only this time for the uuid. This assumes a fact not in evidence, which is that we're going to accept a uuid-generation function as part of core. AFAIK the only reasonably non-contentious part of this proposal is the ability to *store* uuids. Generating new ones introduces a host of portability and other issues. Considering the amount of pain involved in supporting SERIAL in the parser, pg_dump, etc, I'd say that adding the above is a pretty certain route to getting your patch rejected as too invasive. If, three or four versions down the road, large numbers of people are using uuid with the same generation function, *then* it might be time to think about introducing a macro type. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
