Обсуждение: 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
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 internallymeans 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: >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 > >-- >Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-hackers
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: @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: @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 > > -- > 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
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
On Jul 12, 2011, at 1:24 PM, 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. > >> 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? How about we just leave it alone? I think this is a solution in search of a problem. ...Robert
Thom, > 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 Oh! I guess that shows you how much I use the type then. Well, in that case, this whole discussion is moot unless someone is offering to write us a UUID generator from scratch. Is someone doing so? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 07/12/2011 11:56 AM, Josh Berkus wrote: > Thom, > >> 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 > > Oh! > > I guess that shows you how much I use the type then. > > Well, in that case, this whole discussion is moot unless someone is > offering to write us a UUID generator from scratch. Is someone doing so? I am reaching back into my mental archives for when we first decided to implement a UUID datatype. As I recall we purposely did not include the generators in core because every language already has their own generators, popular languages anyway. I think we should just leave it as be, note to use your native language generator OR use the contributed modules. JD -- 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 09:15 AM, Andrew Dunstan wrote: > > > 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? It is an extra step, that is less usable. Does it matter? Shrug, I know I hate having to type apt-get just to use xyz, does it mean it is a big deal? Probably not. -- 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 03:44 PM, Joshua D. Drake wrote: >> >> What about extensions makes them less usable? > > > It is an extra step, that is less usable. Does it matter? Shrug, I > know I hate having to type apt-get just to use xyz, does it mean it is > a big deal? Probably not. By that argument we wouldn't have any extensions at all, just a monolithic product. I don't think that would be an advance. cheers andrew
On Tue, Jul 12, 2011 at 04:29:33PM -0400, Andrew Dunstan wrote: > > > On 07/12/2011 03:44 PM, Joshua D. Drake wrote: > >> > >>What about extensions makes them less usable? > > > > > >It is an extra step, that is less usable. Does it matter? Shrug, I > >know I hate having to type apt-get just to use xyz, does it mean > >it is a big deal? Probably not. > > > By that argument we wouldn't have any extensions at all, just a > monolithic product. I don't think that would be an advance. > > cheers > > andrew > For me, the criteria I like to use for core functionality are: 1. It is available with a common definition from a number of DB products. With a UUID, it's size/structure is predefined and this allows a dump from another SQL product to be loaded into a PostgreSQL DB. 2. It would benefit from the tighter integration with the core DB for either performance or development use. 3. It is a feature where the "extra step" is an unexpected nuisance. That is why I think having the UUID generators be a contrib module is the correct place for them to be, but the UUID type is better as a core function. Regards, Ken
On 07/12/2011 01:29 PM, Andrew Dunstan wrote: > > > On 07/12/2011 03:44 PM, Joshua D. Drake wrote: >>> >>> What about extensions makes them less usable? >> >> >> It is an extra step, that is less usable. Does it matter? Shrug, I >> know I hate having to type apt-get just to use xyz, does it mean it is >> a big deal? Probably not. > > > By that argument we wouldn't have any extensions at all, just a > monolithic product. I don't think that would be an advance. By that argument, with a condition of what we are talking about. I think what this boils down to is we look at what our competitors are doing. If we were to change anything at all. > > cheers > > andrew > > > -- 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 Jul 12, 2011, at 1:40 PM, ktm@rice.edu wrote: > That is why I think having the UUID generators be a contrib module > is the correct place for them to be, but the UUID type is better as > a core function. I'm okay with this, though given the fact that ftp.ossp.org has been down for *months*, I'm inclined to think that we oughtto include it in the contrib distribution for easy linking. Best, David
David, > I'm okay with this, though given the fact that ftp.ossp.org has been down for *months*, I'm inclined to think that we oughtto include it in the contrib distribution for easy linking. What license is it under? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
"David E. Wheeler" <david@kineticode.com> writes:
> On Jul 12, 2011, at 1:40 PM, ktm@rice.edu wrote:
>> That is why I think having the UUID generators be a contrib module
>> is the correct place for them to be, but the UUID type is better as
>> a core function.
> I'm okay with this, though given the fact that ftp.ossp.org has been
> down for *months*,
Curious considering that the machine is there (responds to ping), and
the ossp.org webserver works fine. Has anyone bugged the owner about
that?
> I'm inclined to think that we ought to include it in the contrib distribution for easy linking.
I'm disinclined to do anything that might amount to forking the library,
or even looking like we wanted to take responsibility for it.
regards, tom lane
On Jul 12, 2011, at 5:07 PM, Tom Lane wrote: > Curious considering that the machine is there (responds to ping), and > the ossp.org webserver works fine. Has anyone bugged the owner about > that? I've sent him email and Twitter DMs, to no avail. Best, David
On Jul 12, 2011, at 5:06 PM, Josh Berkus wrote: >> I'm okay with this, though given the fact that ftp.ossp.org has been down for *months*, I'm inclined to think that weought to include it in the contrib distribution for easy linking. > > What license is it under? COPYRIGHT AND LICENSE Copyright (c) 2004-2008 Ralf S. Engelschall <rse@engelschall.com> Copyright (c) 2004-2008 The OSSP Project <http://www.ossp.org/> This file is part of OSSP uuid, a library for the generation of UUIDs which can found at http://www.ossp.org/pkg/lib/uuid/ Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Um, Although I have not caught up with this thread. Ralf-san and the member of OSSP are maintaining OSSP continuously. I think that a reaction can merely be obtained in the intervals of when busy. Please do not need fast response. (2011/07/13 11:35), David E. Wheeler wrote: > On Jul 12, 2011, at 5:07 PM, Tom Lane wrote: > >> Curious considering that the machine is there (responds to ping), and >> the ossp.org webserver works fine. Has anyone bugged the owner about >> that? > > I've sent him email and Twitter DMs, to no avail. > > Best, > > David > >
On Jul 13, 2011, at 6:44 AM, Hiroshi Saito wrote: > Um, Although I have not caught up with this thread. > > Ralf-san and the member of OSSP are maintaining OSSP continuously. > I think that a reaction can merely be obtained in the intervals of when busy. Please do not need fast response. I have not been able to connect to ftp.ossp.org for months. Months. David
Hi Thomas-san, Ralf-san. I appreciate your great work. Thanks! CC to Postgres-ML. Regards, Hiroshi Saito (2011/07/14 3:49), Thomas Lotterer wrote:> Thanks for the hint.> Our ftp daemon is dumping core.> We are debugging ...>
On Jul 14, 2011, at 12:05 AM, Hiroshi Saito wrote: > Hi Thomas-san, Ralf-san. > > I appreciate your great work. > Thanks! > > CC to Postgres-ML. > > Regards, > Hiroshi Saito > > (2011/07/14 3:49), Thomas Lotterer wrote: > > Thanks for the hint. > > Our ftp daemon is dumping core. > > We are debugging ... Ah, good news, thanks. Where should I report stuff like this in the future? I sent a message about this to rse@engelschall.com on May 15th and alsoa Twitter DM but didn't hear back… Thanks, David
On Jul 14, 2011, at 9:53 AM, David E. Wheeler wrote: >> (2011/07/14 3:49), Thomas Lotterer wrote: >>> Thanks for the hint. >>> Our ftp daemon is dumping core. >>> We are debugging ... > > Ah, good news, thanks. > > Where should I report stuff like this in the future? I sent a message about this to rse@engelschall.com on May 15th andalso a Twitter DM but didn't hear back… Hi Thomas, Did you ever get your FTP server fixed? I'm still not able to download uuid: curl -O ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0 curl: (7) couldn't connect to host Thanks, David