Re: Proposal for GUID datatype - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Proposal for GUID datatype
Date
Msg-id 20060909102016.F64799@megazone.bigpanda.com
Whole thread Raw
In response to Re: Proposal for GUID datatype  (Jan de Visser <jdevisser@digitalfairway.com>)
List pgsql-hackers
On Sat, 9 Sep 2006, Jan de Visser wrote:

> On Saturday 09 September 2006 01:33, mark@mark.mielke.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?


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: log_duration is redundant, no?
Next
From: David Fetter
Date:
Subject: Re: log_duration is redundant, no?