Added to TODO:
* Allow the UUID type to accept non-standard formats
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01214.php
---
Dawid Kuroczko wrote:
> Hello.
>
> I am currently playin
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> This seems like a good enough opportunity to mention an idea that I
> had while/after doing the enum patch. The patch was fairly intrusive
> for something that was just adding a type because postgresql isn't
> really set up for parameterized types other t
On Fri, Feb 29, 2008 at 9:26 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > "Be conservative in what you send, and liberal in what you accept."
>
> Yeah, I was about to quote that same maxim myself. I don't have a big
> problem with allowing uuid_in to
James Mansion wrote:
Mark Mielke wrote:
I recall there being a measurable performance difference between the
most liberal parser, and the most optimized parser, back when I wrote
one for PostgreSQL. I don't know how good the one in use for
PostgreSQL 8.3 is. As to whether the cost is noticeabl
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> "Be conservative in what you send, and liberal in what you accept."
Yeah, I was about to quote that same maxim myself. I don't have a big
problem with allowing uuid_in to accept known format variants. (I'm
not sure about allowing a hyphen *anywhere*,
On Thu, Feb 28, 2008 at 06:45:18PM -0500, Mark Mielke wrote:
> My personal opinion is that this is entirely a philosophical issue, and
> that both sides have merits.
I think it depends on what you're optimising for: initial development
time, maintaince time or run time.
> There is no reason for
Mark Mielke wrote:
I recall there being a measurable performance difference between the
most liberal parser, and the most optimized parser, back when I wrote
one for PostgreSQL. I don't know how good the one in use for
PostgreSQL 8.3 is. As to whether the cost is noticeable to people or
not -
James Mansion wrote:
Kenneth Marshall wrote:
conversion process themselves. Accepting random input puts a performance
hit on everybody following the standard.
Why is that necessarily the case?
Why not have a liberal parser and a configurable switch that
determines whether non-standard
forms a
Kenneth Marshall wrote:
conversion process themselves. Accepting random input puts a performance
hit on everybody following the standard.
Why is that necessarily the case?
Why not have a liberal parser and a configurable switch that determines
whether non-standard
forms are liberally accepted
On Thu, Feb 28, 2008 at 08:06:46PM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > > Well, I guess the question is: if we don't offer some builtin way to
> render
> > > non-standard formats built into company products, will those
> companies fix
> > > their format or just not use PostgreSQL?
> >
> > Well, I guess the question is: if we don't offer some builtin way to
render
> > non-standard formats built into company products, will those
companies fix
> > their format or just not use PostgreSQL?
>
> Well, there is an advantage that Postgres has that some others don't:
you
> can extend
On Thu, Feb 28, 2008 at 08:58:01AM -0800, Josh Berkus wrote:
> Well, I guess the question is: if we don't offer some builtin way to render
> non-standard formats built into company products, will those companies fix
> their format or just not use PostgreSQL?
Well, there is an advantage that Pos
Tom,
> I think the question we have to answer is whether we want to be
> complicit in the spreading of a nonstandard UUID format. Even if
> we answer "yes" for this HP case, it doesn't follow that we should
> create a mechanism for anybody to do anything with 'em. That way
> lies the madness peo
On Thu, Feb 28, 2008 at 1:19 AM, Tom Lane wrote:
> I think the question we have to answer is whether we want to be
> complicit in the spreading of a nonstandard UUID format.
I don't.
I have patched the UUID input and output functions to be compatible
with Adobe ColdFusion (http://adobe.com/prod
Josh Berkus <[EMAIL PROTECTED]> writes:
>> I am working on a patch to support this format (yes, it is a simple
>> modification).
> I'd suggest writing a formatting function for UUIDs instead.
That seems like overkill, if not outright encouragement of people to
come up with yet other nonstandard f
> > I am working on a patch to support this format (yes, it is a simple
> > modification).
There was a proposal and a discussion regarding how this datatype would be
before I started developing it. We decided to go with the format proposed in
RFC. Unless there is strong case, I doubt any non sta
Dawid,
> I am working on a patch to support this format (yes, it is a simple
> modification).
I'd suggest writing a formatting function for UUIDs instead. Not sure what
it should be called, though. "to_char" is pretty overloaded right now.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisc
Hello.
I am currently playing with UUID data type and try to use it to store provided
by third party (Hewlett-Packard) application. The problem is they
format UUIDs as
-------, so I have to
replace(text,'-','')::uuid for
this kind of data.
Nooow, the case is quite
18 matches
Mail list logo
