| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | Jan de Visser <jdevisser(at)digitalfairway(dot)com> |
| Cc: | mark(at)mark(dot)mielke(dot)cc, pgsql-hackers(at)postgresql(dot)org, Gevik Babakhani <pgdev(at)xs4all(dot)nl> |
| Subject: | Re: Proposal for GUID datatype |
| Date: | 2006-09-09 17:26:08 |
| Message-ID: | 20060909102016.F64799@megazone.bigpanda.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 9 Sep 2006, Jan de Visser wrote:
> On Saturday 09 September 2006 01:33, mark(at)mark(dot)mielke(dot)cc wrote:
> > I don't think so. If it isn't 128 bits - and you want to fit it into
> > 128 bits, it means padding. Where should the padding go? As application
> > specific, it is up to the application to convert.
>
> I am not saying that. I am just saying that you shouldn't limit yourself to
> any particular input formats.
I'd wonder if it'd be better to have a set of literal formats and "input"
functions like to_guid(text, text) for more complicated cases. The broader
we make the literal format, the harder it is to determine if the input
actually is what was intended. For example, did the user mean to put that
ipv6 address in this guid column and what about this other ipv6 address
looking thing which is abbreviated, are we putting in what the user
expects?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksandar Dezelin | 2006-09-09 17:47:19 | Re: TODO item: GUID |
| Previous Message | Peter Eisentraut | 2006-09-09 16:33:10 | Re: log_duration is redundant, no? |