Full GUID support
I would like to request that full support for the UUID data type can added.
I think that even though there is a contrib module, since this is a standard
datatype that Postgres ought to be the one actually assigning the value.
Best Regards
Michael Gould
--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax
On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:
I would like to request that full support for the UUID data type can added.
I think that even though there is a contrib module, since this is a standard
datatype that Postgres ought to be the one actually assigning the value.
What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.
Peter,
I don't believe that the library that the contrib module runs with can run
on Window 64 bit servers or even Windows 7 64 bit. That is problem as most
shops are using 64 bit OS and if Window the contrib module is going to fail.
Taking the responsibility to handle this internally means that you can
write your own implementation not based on a libary that can't handle
Windows 64 bit.
Best Regards
Michael Gould
"Peter Eisentraut" wrote:
On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:
I would like to request that full support for the UUID data type can
added.
I think that even though there is a contrib module, since this is a
standard
datatype that Postgres ought to be the one actually assigning the value.
What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax
On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:
> Peter,
>
> I don't believe that the library that the contrib module runs with can run
> on Window 64 bit servers or even Windows 7 64 bit. That is problem as most
> shops are using 64 bit OS and if Window the contrib module is
going to fail.
> Taking the responsibility to handle this internally means that you can
> write your own implementation not based on a libary that can't handle
> Windows 64 bit.
The next release of the installers will, now that we have a 64 Windows
port of ossp-uuid.
Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Dave Page <dpage@pgadmin.org> writes:
Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.
Michael: this is something that was discussed before, when we agreed
to put the uuid type but not the generator functions in core. See
the archives. Nothing about the situation has changed since then.
regards, tom lane
Does this look to be something that will surface around for 9.1
Sent from Samsung mobile
Dave Page <dpage@pgadmin.org> wrote:
Show quoted text
On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:
> Peter,
>
> I don't believe that the library that the contrib module runs with can run
> on Window 64 bit servers or even Windows 7 64 bit. That is problem as most
> shops are using 64 bit OS and if Window the contrib module is
going to fail.
> Taking the responsibility to handle this internally means that you can
> write your own implementation not based on a libary that can't handle
> Windows 64 bit.The next release of the installers will, now that we have a 64 Windows
port of ossp-uuid.Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnakeEnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Resolved by subject fallback
Should be in 9.0.5/9.1b3
On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:
> Does this look to be something that will surface around for 9.1
>
> Sent from Samsung mobile
>
> Dave Page <dpage@pgadmin.org> wrote:
>
>>On Sunday, July 3, 2011, Michael Gould
>><mgould@intermodalsoftwaresolutions.net> wrote:
>>&gt; Peter,
>>&gt;
>>&gt; I don't believe that the library that the contrib
module runs with can run
>>&gt; on Window 64 bit servers or even Windows 7 64 bit.
That is problem as most
>>&gt; shops are using 64 bit OS and if Window the contrib module is
>>going to fail.
>>&gt; Taking the responsibility to handle this internally
means that you can
>>&gt; write your own implementation not based on a libary
that can't handle
>>&gt; Windows 64 bit.
>>
>>The next release of the installers will, now that we have a 64 Windows
>>port of ossp-uuid.
>>
>>Even If that weren't the case, integrating the type wouldn't fix the
>>problem anyway, unless you're suggesting we implement our own UUID
>>generator (which isn't nearly as straightforward as it might seem, as
>>I understand it)..
>>
>>--
>>Dave Page
>>Blog: http://pgsnake.blogspot.com
>>Twitter: @pgsnake
>>
>>EnterpriseDB UK: http://www.enterprisedb.com
>>The Enterprise PostgreSQL Company
>>
>>--
>>Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>>To make changes to your subscription:
>>http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Dave,
This is wonderful news.
Best Regards
Michael Gould
"Dave Page" <dpage@pgadmin.org> wrote:
Should be in 9.0.5/9.1b3
On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:Does this look to be something that will surface around for 9.1
Sent from Samsung mobile
Dave Page <dpage@pgadmin.org> wrote:
On Sunday, July 3, 2011, Michael Gould
<mgould@intermodalsoftwaresolutions.net> wrote:Peter,
I don't believe that the library that the contrib
module runs with can run
on Window 64 bit servers or even Windows 7 64 bit.
That is problem as most
shops are using 64 bit OS and if Window the contrib module is
going to fail.
Taking the responsibility to handle this internally
means that you can
write your own implementation not based on a libary
that can't handle
Windows 64 bit.
The next release of the installers will, now that we have a 64 Windows
port of ossp-uuid.Even If that weren't the case, integrating the type wouldn't fix the
problem anyway, unless you're suggesting we implement our own UUID
generator (which isn't nearly as straightforward as it might seem, as
I understand it)..--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnakeEnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnakeEnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250 fax
On sön, 2011-07-03 at 17:02 -0400, Tom Lane wrote:
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.
There is a standard, and it defines four ways to create UUIDs. AFAIR,
no one has ever claimed that there is another recognized way that we
don't support. So I don't think that's really the argument. The
argument was that we don't want to bother.
On 7/3/11 2:02 PM, Tom Lane wrote:
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.
Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On Sun, Jul 10, 2011 at 20:59, Josh Berkus <josh@agliodbs.com> wrote:
On 7/3/11 2:02 PM, Tom Lane wrote:
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.
UUID *is* in core. It's just the generation functions that aren't.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Jul 10, 2011 at 20:59, Josh Berkus <josh@agliodbs.com> wrote:
Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.
UUID *is* in core. It's just the generation functions that aren't.
Remind me again *why* it's in core? Seems like something that ought to
be an extension.
regards, tom lane
On mån, 2011-07-11 at 11:13 -0400, Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Jul 10, 2011 at 20:59, Josh Berkus <josh@agliodbs.com> wrote:
Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.UUID *is* in core. It's just the generation functions that aren't.
Remind me again *why* it's in core? Seems like something that ought to
be an extension.
I think at the time, making something an add-on would have placed an
excessive burden on potential users. The claim was that most UUIDs are
generated by applications, so having the type in core would be
important, but having the generation functions not so much.
That said, there have been several proposals over the years to move a
few things out of the core into add-ons, and now that extension support
exists, we could potentially reopen that discussion.
Excerpts from Peter Eisentraut's message of lun jul 11 11:48:22 -0400 2011:
That said, there have been several proposals over the years to move a
few things out of the core into add-ons, and now that extension support
exists, we could potentially reopen that discussion.
Surely we ought to find a way to distribute binaries first, at least for
those platforms on which compiling stuff from source is cumbersome.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 07/10/2011 11:59 AM, Josh Berkus wrote:
On 7/3/11 2:02 PM, Tom Lane wrote:
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between that and the lack of portability of
many of the better ways, this is something I'm happy to keep at arm's
length.Also, I think that UUIDs fall into the class of "datatypes used by less
than 10% of users" which should always remain extensions. I'd consider
CITEXT for core before UUID.
Uh.... UUID/GUID is used pervasively throughout enterprise apps,
especially Java apps.
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579
I'd have to agree on the importance of UUID support. It's pretty much
essential for any sort of disconnected sync model. We use UUIDs
(generated with the "guid.comb" technique) for our surrogate keys in
around 50 apps, and it has served us well.
We have also been seriously missing the 64-bit generator
functionality. I've been watching the threads for half a year to see
when it will pop up again. It's been a long wait.
Regarding UUID generation, IMHO, the random approach is the "standard"
at this point. That'd be v4 in the oisp library. It would be handy
to be able to generate these without having to load in special
extensions. It's not the biggest deal though since we can run
initialization code to get the database set up... just more effort.
Patrick Earl
Show quoted text
On Mon, Jul 11, 2011 at 11:19 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
Uh.... UUID/GUID is used pervasively throughout enterprise apps, especially
Java apps.
On 07/03/2011 11:54 AM, Peter Eisentraut wrote:
On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:
I would like to request that full support for the UUID data type can added.
I think that even though there is a contrib module, since this is a standard
datatype that Postgres ought to be the one actually assigning the value.What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.
It is about usability folks.
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579
On 07/12/2011 12:03 PM, Joshua D. Drake wrote:
On 07/03/2011 11:54 AM, Peter Eisentraut wrote:
On sön, 2011-07-03 at 13:42 -0500, Michael Gould wrote:
I would like to request that full support for the UUID data type can
added.
I think that even though there is a contrib module, since this is a
standard
datatype that Postgres ought to be the one actually assigning the
value.What difference would that make? In 9.1, you can easily load the
required extension, and there'd be no difference from a built-in
variant.It is about usability folks.
What about extensions makes them less usable?
cheers
andrew
Magnus, JD,
UUID *is* in core. It's just the generation functions that aren't.
No, it's not. It's in /contrib, which makes it an extension.
Uh.... UUID/GUID is used pervasively throughout enterprise apps,
especially Java apps.
Oh, I guess I encounter it a lot less than you. Time for a survey?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 12 July 2011 19:24, Josh Berkus <josh@agliodbs.com> wrote:
Magnus, JD,
UUID *is* in core. It's just the generation functions that aren't.
No, it's not. It's in /contrib, which makes it an extension.
The functions to produce UUIDs are in contrib, but the UUID data type
itself is in core. You get the type uuid whether you install the
contrib module or not.
http://www.postgresql.org/docs/current/static/datatype-uuid.html
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
