Robert Haas wrote:
The attached patch allows uuid_in() to parse a wider variety of
variant input formats for the UUID data type, per the TODO named in
the subject line.
I have committed your patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Dawid Kuroczko wrote:
2) The '-' is not the only character that people have used. ClearCase uses
'.' and ':' as punctuation.
I would be more in favor of accepting MAC-address style notation AA:BB:CC:DD
also, in that case, but I think its going too far... So, I am for sticking with
dashes
On Oct 10, 2008, at 3:40 PM, Robert Haas wrote:
I dislike all own creatures - because nobody will understand so do
some wrong thing - using non standard formats is bad thing. So
it's is
necessary, then who need it then he found it on pgfoundry. But why
smudge core?
I'm opposed to smudging
1) Reduced error checking.
2) The '-' is not the only character that people have used. ClearCase uses
'.' and ':' as punctuation.
3) People already have the option of translating the UUID from their
application to a standard format.
4) As you find below, and is probably possible to
On Fri, Oct 10, 2008 at 7:28 AM, Mark Mielke [EMAIL PROTECTED] wrote:
Robert Haas wrote:
While we could perhaps accept only those variant formats which we
specifically know someone to be using, it seems likely that people
will keep moving those pesky dashes around, and we'll likely end up
Robert Haas wrote:
1) Reduced error checking.
2) The '-' is not the only character that people have used. ClearCase uses
'.' and ':' as punctuation.
3) People already have the option of translating the UUID from their
application to a standard format.
4) As you find below, and is
Anyways - I only somewhat disagree. I remember the original discussions, and
I remember agreeing with the points to keep PostgreSQL UUID support thin and
rigid. It's valuable for it to be built-in to the database. It's not
necessarily valuable for PostgreSQL to support every UUID version or
Mark Mielke [EMAIL PROTECTED] writes:
Anyways - I only somewhat disagree. I remember the original discussions,
and I remember agreeing with the points to keep PostgreSQL UUID support
thin and rigid. It's valuable for it to be built-in to the database.
It's not necessarily valuable for
3) People already have the option of translating the UUID from their
application to a standard format.
Regexp, the swiss-army knife of data manipulation. ;)
While possible, it really is not that easy and efficient. At least we should
accept dashless UUIDs, so instead of tediously
On 2008-10-10, at 16:01, Tom Lane wrote:
Well, this discussion started with the conventional wisdom about be
conservative in what you send and liberal in what you accept. I'd
still resist emitting any UUID format other than the RFC-approved one,
but I don't see anything very wrong in being
2008/10/10 Tom Lane [EMAIL PROTECTED]:
Mark Mielke [EMAIL PROTECTED] writes:
Anyways - I only somewhat disagree. I remember the original discussions,
and I remember agreeing with the points to keep PostgreSQL UUID support
thin and rigid. It's valuable for it to be built-in to the database.
that only depends on definition of 'common variant'. Will it be just code
that will accept letters and digits, and trying to make that into UUID ?
You are attacking a straw man. No one is proposing that.
I think those who designed their code to produce or accept non standard
UUID, should
I think it will be as expensive to app to convert UUID to standard
format, as it would be too postgrsql.
But if psql does it - everyone would expect it to do it right. You
can't possibly detect all forms of screwed up design, and expect
application to pick it up.
All I say, is I think it
Is it problem do for non standard UUID formats pgfoundry project?
I'm not volunteering set up a pgfoundry project to maintain something
that can be accomplished with a patch that adds 19 lines of new code
(and removes 9). This functionality is useful in core because it will
Just Work. If you
On Fri, Oct 10, 2008 at 3:48 PM, Grzegorz Jaskiewicz
[EMAIL PROTECTED] wrote:
I think it will be as expensive to app to convert UUID to standard format,
as it would be too postgrsql.
But if psql does it - everyone would expect it to do it right. You can't
possibly detect all forms of screwed
2008/10/10 Robert Haas [EMAIL PROTECTED]:
Is it problem do for non standard UUID formats pgfoundry project?
I'm not volunteering set up a pgfoundry project to maintain something
that can be accomplished with a patch that adds 19 lines of new code
(and removes 9). This functionality is useful
I dislike all own creatures - because nobody will understand so do
some wrong thing - using non standard formats is bad thing. So it's is
necessary, then who need it then he found it on pgfoundry. But why
smudge core?
I'm opposed to smudging core, but I'm in favor of this patch. :-)
Of
Robert Haas wrote:
While we could perhaps accept only those variant formats which we
specifically know someone to be using, it seems likely that people
will keep moving those pesky dashes around, and we'll likely end up
continuing to add more formats and arguing about which ones are widely
18 matches
Mail list logo
