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 playing
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
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 people
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
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 Postgres
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,
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
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
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 -
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
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*,
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
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 accept
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 than
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
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 Francisco
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
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 formats
18 matches
Mail list logo
