| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
| Cc: | Gevik Babakhani <pgdev(at)xs4all(dot)nl>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: guid/uuid datatype |
| Date: | 2007-01-25 17:06:48 |
| Message-ID: | 1169744808.5447.43.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2007-01-25 17:13:54 | Re: guid/uuid datatype |
| Previous Message | Stefan Kaltenbrunner | 2007-01-25 16:57:43 | Re: guid/uuid datatype |