Обсуждение: 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.
Gevik Babakhani <pgdev@xs4all.nl> 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
Understood, Thank you :) On Sat, 2006-09-16 at 21:23 -0400, Tom Lane wrote: > Gevik Babakhani <pgdev@xs4all.nl> 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 >
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/
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.
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/
It was
Gevik Babakhani <pgdev@xs4all.nl> 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?
>
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 <pgdev@xs4all.nl> 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/
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.