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 :)
Show quoted text
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
Show quoted text
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.