Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Re: criticism about hosting download packages
Hello, we discussed this a few days ago on the German PostgreSQL channel. Stefan plead to tell it -www. Here is the fact that I most dislike: When you want to download a PostgreSQL package then you get linked to EnterpriseDB. When you now want to download a special package you get a register page. I know it is not mandatory to register but sorry, but that is a kind of fishing for addresses in my eyes. Best Regards, Susanne -- Susanne Ebrecht Bielefeld
2011/2/22 Susanne Ebrecht <miracee(at)web(dot)de>: > Hello, > > we discussed this a few days ago on the German PostgreSQL channel. > Stefan plead to tell it -www. > > Here is the fact that I most dislike: > When you want to download a PostgreSQL package then you get > linked to EnterpriseDB. > When you now want to download a special package you get a register > page. > I know it is not mandatory to register but > sorry, but that is a kind of fishing for addresses in my eyes. > Yes it is. It has already been reported and I believe it won't change on the EDB side :-( (not to say that EDB was known to do that and get some unfortunate glitchs in the past) In our side, we can review the dowload area and add explanations for third parties packages ? This is a rgular topic of -www, and the last time I have been bounced to the 'archive' ... Long history of mails to read before going ahead. > Best Regards, > > Susanne > > -- > Susanne Ebrecht > Bielefeld > > > -- > Sent via pgsql-www mailing list (pgsql-www(at)postgresql(dot)org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-www > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On Tue, Feb 22, 2011 at 10:29, Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote: > 2011/2/22 Susanne Ebrecht <miracee(at)web(dot)de>: >> Hello, >> >> we discussed this a few days ago on the German PostgreSQL channel. >> Stefan plead to tell it -www. >> >> Here is the fact that I most dislike: >> When you want to download a PostgreSQL package then you get >> linked to EnterpriseDB. >> When you now want to download a special package you get a register >> page. >> I know it is not mandatory to register but >> sorry, but that is a kind of fishing for addresses in my eyes. >> > > Yes it is. It has already been reported and I believe it won't change > on the EDB side :-( (not to say that EDB was known to do that and get > some unfortunate glitchs in the past) > In our side, we can review the dowload area and add explanations for > third parties packages ? Yes. And the same applies as last time - please bring a suggestion :-) Preferrably in the form of a patch, or at least a mock-up... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
2011/2/22 Magnus Hagander <magnus(at)hagander(dot)net>: > On Tue, Feb 22, 2011 at 10:29, Cédric Villemain > <cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote: >> 2011/2/22 Susanne Ebrecht <miracee(at)web(dot)de>: >>> Hello, >>> >>> we discussed this a few days ago on the German PostgreSQL channel. >>> Stefan plead to tell it -www. >>> >>> Here is the fact that I most dislike: >>> When you want to download a PostgreSQL package then you get >>> linked to EnterpriseDB. >>> When you now want to download a special package you get a register >>> page. >>> I know it is not mandatory to register but >>> sorry, but that is a kind of fishing for addresses in my eyes. >>> >> >> Yes it is. It has already been reported and I believe it won't change >> on the EDB side :-( (not to say that EDB was known to do that and get >> some unfortunate glitchs in the past) >> In our side, we can review the dowload area and add explanations for >> third parties packages ? Rah, sorry, it was supposed to be a dot not a question-mark. > > Yes. > > And the same applies as last time - please bring a suggestion :-) > Preferrably in the form of a patch, or at least a mock-up... > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
> >> Yes it is. It has already been reported and I believe it won't change > >> on the EDB side :-( (not to say that EDB was known to do that and get > >> some unfortunate glitchs in the past) > >> In our side, we can review the dowload area and add explanations for > >> third parties packages ? > > Rah, sorry, it was supposed to be a dot not a question-mark. The only way the EDB page will not be prominent is if the community starts maintaining its own one-click packages that provide the same level of functionality. Nobody has offered to put that effort in. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
2011/2/22 Joshua D. Drake <jd(at)commandprompt(dot)com>: > >> >> Yes it is. It has already been reported and I believe it won't change >> >> on the EDB side :-( (not to say that EDB was known to do that and get >> >> some unfortunate glitchs in the past) >> >> In our side, we can review the dowload area and add explanations for >> >> third parties packages ? >> >> Rah, sorry, it was supposed to be a dot not a question-mark. > > The only way the EDB page will not be prominent is if the community > starts maintaining its own one-click packages that provide the same > level of functionality. Nobody has offered to put that effort in. I am happy that EDB maintain those packages. It is great and benefit to lot of PostgreSQL users. The issue is not with EDB page being prominent but with the bad taste of the registration form which lead users to confusion. > > JD > > -- > PostgreSQL.org Major Contributor > Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 > Consulting, Training, Support, Custom Development, Engineering > http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt > > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On Tue, 2011-02-22 at 20:44 +0100, Cédric Villemain wrote: > 2011/2/22 Joshua D. Drake <jd(at)commandprompt(dot)com>: > > > >> >> Yes it is. It has already been reported and I believe it won't change > >> >> on the EDB side :-( (not to say that EDB was known to do that and get > >> >> some unfortunate glitchs in the past) > >> >> In our side, we can review the dowload area and add explanations for > >> >> third parties packages ? > >> > >> Rah, sorry, it was supposed to be a dot not a question-mark. > > > > The only way the EDB page will not be prominent is if the community > > starts maintaining its own one-click packages that provide the same > > level of functionality. Nobody has offered to put that effort in. > > I am happy that EDB maintain those packages. It is great and benefit > to lot of PostgreSQL users. > The issue is not with EDB page being prominent but with the bad taste > of the registration form which lead users to confusion. Right but that isn't our concern. EDB should and can do whatever they wish with that download page. It is up to the community to decide whether or not how they handle it is reasonable. EDB *DESERVES* to be able to collect information if a person wants to download THEIR package. It isn't a .Org package. It is a EDB package. I would also note that the page automatically starts downloading the package if you are running any modern browser. It does not require registration at all and even states that on the page. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 22.02.2011 20:53, Joshua D. Drake wrote: > Right but that isn't our concern. EDB should and can do whatever they > wish with that download page. It is up to the community to decide > whether or not how they handle it is reasonable. As long as it is legal. Fishing for addresses is illegal in most European countries. The way EDB tries it might not be illegal - but it is hard at the limit of being illegal. It could end with - that you won't be able to download the packages from all countries - because countries forbid accessing the page. Just my 2 ct and many thousands thanks for all your answers, Susanne -- Susanne Ebrecht Bielefeld
On Wed, Feb 23, 2011 at 11:01 AM, Susanne Ebrecht <miracee(at)web(dot)de> wrote: > On 22.02.2011 20:53, Joshua D. Drake wrote: >> >> Right but that isn't our concern. EDB should and can do whatever they >> wish with that download page. It is up to the community to decide >> whether or not how they handle it is reasonable. > > As long as it is legal. > > Fishing for addresses is illegal in most European countries. > > The way EDB tries it might not be illegal - but it is hard at the limit > of being illegal. Can you provide some evidence for that, frankly outrageous, claim? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-02-23 at 12:01 +0100, Susanne Ebrecht wrote: > On 22.02.2011 20:53, Joshua D. Drake wrote: > > Right but that isn't our concern. EDB should and can do whatever they > > wish with that download page. It is up to the community to decide > > whether or not how they handle it is reasonable. > > As long as it is legal. > > Fishing for addresses is illegal in most European countries. There is no fishing going on here. > > The way EDB tries it might not be illegal - but it is hard at the limit > of being illegal. Susanne this is pretty out there. They aren't fishing for addresses. They don't make you fill out the form. The download starts on its own without putting in a single character of information. The page even states that the download will begin on its own and that if it doesn't you can click the link. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Joshua D. Drake wrote: > On Tue, 2011-02-22 at 20:44 +0100, C?dric Villemain wrote: > > 2011/2/22 Joshua D. Drake <jd(at)commandprompt(dot)com>: > > > > > >> >> Yes it is. It has already been reported and I believe it won't change > > >> >> on the EDB side :-( (not to say that EDB was known to do that and get > > >> >> some unfortunate glitchs in the past) > > >> >> In our side, we can review the dowload area and add explanations for > > >> >> third parties packages ? > > >> > > >> Rah, sorry, it was supposed to be a dot not a question-mark. > > > > > > The only way the EDB page will not be prominent is if the community > > > starts maintaining its own one-click packages that provide the same > > > level of functionality. Nobody has offered to put that effort in. > > > > I am happy that EDB maintain those packages. It is great and benefit > > to lot of PostgreSQL users. > > The issue is not with EDB page being prominent but with the bad taste > > of the registration form which lead users to confusion. > > Right but that isn't our concern. EDB should and can do whatever they > wish with that download page. It is up to the community to decide > whether or not how they handle it is reasonable. Yes, that is correct. The community can accept what EDB has on that page or the community can stop linking to the EDB download site. The point is that the community does have a choice. FYI, the community, through Dave Page and Magnus, used to create click-through installers for Windows, but the EDB installers are better and don't require as much work for the community to produce, and they work on many non-Windows operating systems, and EDB tests and does tech support for those downloads. -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Susanne Ebrecht wrote: > On 22.02.2011 20:53, Joshua D. Drake wrote: > > Right but that isn't our concern. EDB should and can do whatever they > > wish with that download page. It is up to the community to decide > > whether or not how they handle it is reasonable. > > As long as it is legal. > > Fishing for addresses is illegal in most European countries. > > The way EDB tries it might not be illegal - but it is hard at the limit > of being illegal. > > It could end with - that you won't be able to download the packages > from all countries - because countries forbid accessing the page. > > Just my 2 ct and many thousands thanks for all your answers, FYI, it is already not possible to download those installers from countries embargoed by the USA, e.g. Syria, because EDB is headquartered in the USA and has servers in the USA. -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Feb 24, 2011, at 12:33 AM, Bruce Momjian wrote: > Susanne Ebrecht wrote: >> On 22.02.2011 20:53, Joshua D. Drake wrote: >>> Right but that isn't our concern. EDB should and can do whatever they >>> wish with that download page. It is up to the community to decide >>> whether or not how they handle it is reasonable. >> >> As long as it is legal. >> >> Fishing for addresses is illegal in most European countries. >> >> The way EDB tries it might not be illegal - but it is hard at the limit >> of being illegal. >> >> It could end with - that you won't be able to download the packages >> from all countries - because countries forbid accessing the page. >> >> Just my 2 ct and many thousands thanks for all your answers, > > FYI, it is already not possible to download those installers from > countries embargoed by the USA, e.g. Syria, because EDB is headquartered > in the USA and has servers in the USA. with all my personal respect i have for you, bruce ... if EDB wants to turn neutral people in passionate enemies, this is the way to go ... even the mere existence of this discussion shows that there is obviously something going seriously wrong - it is actually the first time that i have seen a discussion about a commercial company doing something like that the way it is done now ... (at least i don't remember anything similar). first of all: i did some cross checking with legal stuff here this evening and what susanne says seems to be true according to some quick investigation. i don't want to elaborate on the details here and i don't want to add 500 more argument why this simply sucks ... just one final word: stop this kind of stuff ... and do it now ... best regards, hans -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de
On Feb 22, 2011, at 8:17 PM, Joshua D. Drake wrote: > >>>> Yes it is. It has already been reported and I believe it won't change >>>> on the EDB side :-( (not to say that EDB was known to do that and get >>>> some unfortunate glitchs in the past) >>>> In our side, we can review the dowload area and add explanations for >>>> third parties packages ? >> >> Rah, sorry, it was supposed to be a dot not a question-mark. > > The only way the EDB page will not be prominent is if the community > starts maintaining its own one-click packages that provide the same > level of functionality. Nobody has offered to put that effort in. > > JD then i suggest that we stick our heads together tomorrow 6am and make it come true ... if assistance is needed - drop me a line; give me a call ... it simply cannot go on like that. many thanks, hans -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de
> first of all: i did some cross checking with legal stuff here this evening and what susanne says seems to be true according to some quick investigation.
> i don't want to elaborate on the details here and i don't want to add 500 more argument why this simply sucks ...
> just one final word: stop this kind of stuff ... and do it now ...
Hans, you are not an attorney.
If you go to the EDB download page, the download begins automatically.
The page tells you that downloads begin automatically. There's a link
if downloads don't begin automatically. The registration form makes it
clear that it's for EDB extras.
So I really don't see what the problem is.
Back in 2007, at Sun I hired an industry analyst to do research give me
a list of the 5 biggest items inhibiting PostgreSQL community growth and
large enterprise adoption. The lack of "all-in-one packages" was item
#3. The fact that EnterpriseDB eliminated that item has expanded our
community and user base to many people who never tried PostgreSQL before.
The one-click packages are important. We do not have the volunteer
resources as a community to produce them without EDB's help. If we tell
EDB to get rid of their registration form, they will simply not produce
them.
So unless you're volunteering the resources of Cybertec to take over
production of the one-click packages, this is a pointless discussion.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Thu, 2011-02-24 at 15:14 -0800, Josh Berkus wrote: > So unless you're volunteering the resources of Cybertec to take over > production of the one-click packages, this is a pointless discussion. > He did in his last email. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, Feb 24, 2011 at 11:14 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote: > > So unless you're volunteering the resources of Cybertec to take over > production of the one-click packages, this is a pointless discussion. FYI, we're currently using somewhere around $30K's worth of hardware for the builds, and have a team of 4 people plus myself who put a significant number of hours into this work. Minor release days involve 40+ man hours of QA work over one to two days, and around 50 different VMware instances (and hardware to run them on) for testing on different platforms. On top of that, there's the development time, and non-trivial amounts of work figuring out weird installation issues that can crop up in complex Windows environments - some of which we wouldn't have figured out without resources such as MSDN subscriptions (which are not cheap either). It is not cheap, or easy to produce the installers, despite what some people seem to think. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Feb 24, 2011 at 5:26 PM, PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> wrote: > with all my personal respect i have for you, bruce ... > if EDB wants to turn neutral people in passionate enemies, this is the way to go ... > even the mere existence of this discussion shows that there is obviously something going seriously wrong - it is actually the first time that i have seen a discussion about a commercial company doing something like that the way it is done now ... (at least i don't remember anything similar). > > first of all: i did some cross checking with legal stuff here this evening and what susanne says seems to be true according to some quick investigation. > i don't want to elaborate on the details here and i don't want to add 500 more argument why this simply sucks ... > just one final word: stop this kind of stuff ... and do it now ... I'm a bit confused by this reaction, to be honest. Let's suppose (contrary to fact) that EnterpriseDB did require people to register before allowing them to download the EnterpriseDB installers. I do not think that would be illegal. Many companies require registration to download software. Some of them also require you to pay money, or agree to legal terms and conditions. If you want a copy of Microsoft Windows, or the Cisco VPN Client, or World of Warcraft, or the Apple Developer Tools, you cannot just go download it (or at least not legally). You have to tell them who you are first and agree to a bunch of stuff, and possibly fork over your credit card number. Considering the number of companies that do this, it is unlikely that it is illegal. And if it is legal to require registration, it would be very surprising if it were legal to suggest it, but not require it, which is what EnterpriseDB is doing. Nor is EnterpriseDB the only company to take this approach. For example, Adobe does exactly the same thing when you download Adobe Reader. If someone wants to make the argument that what EnterpriseDB is doing is illegal, I would like to hear an explanation of how it is different from the Adobe Reader case. Of course, even if it is legal, it may not be what the community wants. This is another issue. It is certainly the community's prerogative to decide which downloads will be linked off of the community web site, and what policy it will have. For example, there is a policy that blogs which are syndicated on Planet PostgreSQL must not contain advertising in the syndicated part of the blog posting. There is an as-far-as-I-know-unwritten part of the policy that forbids even blatant commercialism, as evidenced by the outcry some months ago when Theo Schlossnagle posted some reflections on what makes a good DBA that ended with a note that he was at that time looking to hire such people. Bruce, Dave, and I have been very careful to adhere to this policy in our blog postings, which are no more commercial than anything else on Planet PostgreSQL, and less than several (Circonus and Banqsys being a couple of recent examples). As far as I am aware, however, there is no clearly-defined policy about the downloads page, which seems to have stuff added to it and removed from it on a fairly regular basis based mostly on (1) who asks to be added and (2) who actually puts in the work to keep their packages up to date - and in particular, to have minor releases ready for download *before* the release announcement hits the mailing lists. And as far as the downloads pages go, I would also note that the OpenSCG installers are quite a bit *more* in-your-face about demanding registration than the EnterpriseDB installers - you have to explicitly say you don't want to before it lets you download. And then there are these BitNami things, where I'm not even sure I can find the download link, but there are certainly a lot of links to other things that BitNami does and some suggestions to use their forums and services, and of course links to their sponsor BitRock. As you might or might not guess, I don't speak for EnterpriseDB on any of this and have no involvement in building the packages and no influence on the design of our corporate web site, but I do think that EnterpriseDB should be held to the same standard as (1) other software companies, as regards legality, and (2) other people who have links on the www.postgresql.org site, as regards community policy. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
PostgreSQL - Hans-Jrgen Schnig wrote: > On Feb 24, 2011, at 12:33 AM, Bruce Momjian wrote: > > > Susanne Ebrecht wrote: > >> On 22.02.2011 20:53, Joshua D. Drake wrote: > >>> Right but that isn't our concern. EDB should and can do whatever they > >>> wish with that download page. It is up to the community to decide > >>> whether or not how they handle it is reasonable. > >> > >> As long as it is legal. > >> > >> Fishing for addresses is illegal in most European countries. > >> > >> The way EDB tries it might not be illegal - but it is hard at the limit > >> of being illegal. > >> > >> It could end with - that you won't be able to download the packages > >> from all countries - because countries forbid accessing the page. > >> > >> Just my 2 ct and many thousands thanks for all your answers, > > > > FYI, it is already not possible to download those installers from > > countries embargoed by the USA, e.g. Syria, because EDB is headquartered > > in the USA and has servers in the USA. > > > with all my personal respect i have for you, bruce ... if EDB wants > to turn neutral people in passionate enemies, this is the way to go > ... even the mere existence of this discussion shows that there is > obviously something going seriously wrong - it is actually the first > time that i have seen a discussion about a commercial company doing > something like that the way it is done now ... (at least i don't > remember anything similar). > > first of all: i did some cross checking with legal stuff here this > evening and what susanne says seems to be true according to some quick > investigation. i don't want to elaborate on the details here and i > don't want to add 500 more argument why this simply sucks ... just > one final word: stop this kind of stuff ... and do it now ... Hans, I am not sure what part of my email you are commenting on, but based on your quote of my email above I assume is it the embargoed countries like Syria. We did have an email thread about this in June of 2010: http://archives.postgresql.org/pgsql-www/2010-06/msg00046.php The conclusion was that there is no way to distribute files produced by any USA company to embargoed countries like Syria. It isn't a crypto issue but just any software: http://archives.postgresql.org/pgsql-www/2010-06/msg00137.php Not sure what we can do about this except try to get a non-USA company to produce installers. If it is the email registration page that is bothering you, I only stated that the community has a choice to link to EDB or not. I assume the community can ask for the page to be changed, and EDB can agree or not. If they don't agree, the community can live with it or stop linking to it. -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, 2011-02-24 at 23:28 +0000, Dave Page wrote: > It is not cheap, or easy to produce the installers, despite what some > people seem to think. +1. I know how hard you guys are working hard on QA process. Personally, as a community guy (not an EDB employee), I'm pretty much happy that a company is spending funds on installers. As Josh stated, they increased visibility of PostgreSQL a lot. Given that registration is not a must, I'm ok with giving link to the current website instead of removing it without a real valid reason. Oh, and of course, if community can provide installers that have *at least* the same quality, I'll vote for removing links to EDB page -- but as you wrote, people seem to underestimate the manpower to build binary packages, so I actually don't expect someone to step up the plate and build pure community packages. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Le 25/02/2011 00:14, Josh Berkus a écrit : > >> first of all: i did some cross checking with legal stuff here this evening and what susanne says seems to be true according to some quick investigation. >> i don't want to elaborate on the details here and i don't want to add 500 more argument why this simply sucks ... >> just one final word: stop this kind of stuff ... and do it now ... > > Hans, you are not an attorney. > > If you go to the EDB download page, the download begins automatically. > The page tells you that downloads begin automatically. There's a link > if downloads don't begin automatically. The registration form makes it > clear that it's for EDB extras. > > So I really don't see what the problem is. > > Back in 2007, at Sun I hired an industry analyst to do research give me > a list of the 5 biggest items inhibiting PostgreSQL community growth and > large enterprise adoption. The lack of "all-in-one packages" was item > #3. The fact that EnterpriseDB eliminated that item has expanded our > community and user base to many people who never tried PostgreSQL before. > > The one-click packages are important. We do not have the volunteer > resources as a community to produce them without EDB's help. If we tell > EDB to get rid of their registration form, they will simply not produce > them. > > So unless you're volunteering the resources of Cybertec to take over > production of the one-click packages, this is a pointless discussion. > I completely agree with Josh. This issue comes from time to time, and is getting crazier at each time. I believe now is the time for me to vote for EDB. EDB does a lot of work to make the one-click installer a really nice and usefull tool. They allow people to download it without requiring to register for it. We may not like their download webpage, but they have the right to choose what they put on their webpages, and the community has the right to decide if it wants to link to it or not. And right now, as the community doesn't have the same kind of installer, I think we need to keep the link. It's really usefull for many people (I suppose mostly Windows users). So, instead of bashing them, we should thank them for this nice tool. BTW, I'm not an EDB employee, so... -- Guillaume http://www.postgresql.fr http://dalibo.com
On Thu, Feb 24, 2011 at 11:37 PM, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote: > Le 25/02/2011 00:14, Josh Berkus a écrit : >> >>> first of all: i did some cross checking with legal stuff here this evening and what susanne says seems to be true according to some quick investigation. >>> i don't want to elaborate on the details here and i don't want to add 500 more argument why this simply sucks ... >>> just one final word: stop this kind of stuff ... and do it now ... >> >> Hans, you are not an attorney. >> >> If you go to the EDB download page, the download begins automatically. >> The page tells you that downloads begin automatically. There's a link >> if downloads don't begin automatically. The registration form makes it >> clear that it's for EDB extras. >> >> So I really don't see what the problem is. >> >> Back in 2007, at Sun I hired an industry analyst to do research give me >> a list of the 5 biggest items inhibiting PostgreSQL community growth and >> large enterprise adoption. The lack of "all-in-one packages" was item >> #3. The fact that EnterpriseDB eliminated that item has expanded our >> community and user base to many people who never tried PostgreSQL before. >> >> The one-click packages are important. We do not have the volunteer >> resources as a community to produce them without EDB's help. If we tell >> EDB to get rid of their registration form, they will simply not produce >> them. >> >> So unless you're volunteering the resources of Cybertec to take over >> production of the one-click packages, this is a pointless discussion. >> > > I completely agree with Josh. This issue comes from time to time, and is > getting crazier at each time. I believe now is the time for me to vote > for EDB. > > EDB does a lot of work to make the one-click installer a really nice and > usefull tool. They allow people to download it without requiring to > register for it. We may not like their download webpage, but they have > the right to choose what they put on their webpages, and the community > has the right to decide if it wants to link to it or not. > > And right now, as the community doesn't have the same kind of installer, > I think we need to keep the link. It's really usefull for many people (I > suppose mostly Windows users). > > So, instead of bashing them, we should thank them for this nice tool. > > BTW, I'm not an EDB employee, so... And MySQL is no better: http://dev.mysql.com/downloads/mirror.php?id=400397 (though, as always, we may have better wording) This conversation consumes the valuable and scare time of some very smart folks. Perhaps no more should be spent on this topic? -- Rob Wultsch wultsch(at)gmail(dot)com
Le 23/02/2011 12:01, Susanne Ebrecht a écrit : > On 22.02.2011 20:53, Joshua D. Drake wrote: >> Right but that isn't our concern. EDB should and can do whatever they >> wish with that download page. It is up to the community to decide >> whether or not how they handle it is reasonable. > > As long as it is legal. > > Fishing for addresses is illegal in most European countries. > > The way EDB tries it might not be illegal - but it is hard at the limit > of being illegal. > Seriously Susanne, you can't write something like that on a public mailing-list without giving at least some clear arguments. If you have any evidence or a real-life example of that legal threat, please tell us. Otherwise this is pure FUD and it's very sad to see such thing happening inside our community. -- damien clochard dalibo.com | dalibo.org
Hello Robert, On 25.02.2011 03:57, Robert Haas wrote: > company to take this approach. For example, Adobe does exactly the > same thing when you download Adobe Reader. FYI: that is totally wrong. Adobe not even shows a register page. I just tested. Maybe they show it in US - When you download Adobe Reader by having German IP then the page looks very modest. You only have a big Download button on the page. No register form at all. Same with Microsoft - Free Software from Microsoft - you can download and there is just a huge Download button. For downloading Windows you will get linked to German vendors. I think the discussion came up - because we have to deal here with culture differences - between some European countries and US / UK. Please consider, the intention of my first email wasn't for blaming EnterpriseDB - far from it! Vise versa - it was meant as friendly hint that it might be against morality in some countries. Let me give you some background: Fishing for customers is illegal in Germany. You will find it in our unfair competition law. Also our privacy protection laws point out that you are only allowed to collect data from persons when you really need them - and you are only allowed to collect that kind of data from persons that you really need. Additionally, we have business morality rules. Maybe Germany has the most strict laws here to protect persons and smaller companies for bigger competitors. But I saw there are also EU Guidelines for it. There already were discussion in German government to install a software to block sides with fishing elements. So that you can't access these pages with a German IP. I think it is just a question of time - when they really install that software. Susanne -- Susanne Ebrecht Bielefeld
On Fri, 2011-02-25 at 10:23 +0100, Susanne Ebrecht wrote: > Fishing for customers is illegal in Germany. You will find it in our > unfair competition law. Susanne, choose your words more carefully, and take a breath before sending email. > I think the discussion came up - because we have to deal here with > culture differences - between some European countries and US / UK. Nope. It is not culture, etc. I still am not sure that you are really looking at the page. Download starts in 5 seconds automatically. What else are you expecting? Talk is cheap. Please show us the *Community* PostgreSQL Installer which has at least the current quality *and* which works on various platforms *and* which go under a heavy QA process *and* which is free. If you do this, I'll be more than happy to remove EDB link from our website as a website committer, and give the link to the new installer -- assuming that they will be distributed from postgresql.org, nowhere else. I'm a packager, and I really dislike the attitude towards people/companies who are spending too much time (more than you can think of) on binary packages. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Fri, Feb 25, 2011 at 9:23 AM, Susanne Ebrecht <miracee(at)web(dot)de> wrote: > > Let me give you some background: > > Fishing for customers is illegal in Germany. You will find it in our > unfair competition law. You'd better tell Suse/Novell about that then - I'm sure they'll be pleased to be told that the form on the front page of their website (which comes and goes - might need a few refreshes) is illegal, or that they can't require registration to download SLED and other products. I guess they just don't spend enough on their lawyers. http://www.suse.de/ -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 25 February 2011 09:47, Dave Page <dpage(at)pgadmin(dot)org> wrote: > On Fri, Feb 25, 2011 at 9:23 AM, Susanne Ebrecht <miracee(at)web(dot)de> wrote: >> >> Let me give you some background: >> >> Fishing for customers is illegal in Germany. You will find it in our >> unfair competition law. > > You'd better tell Suse/Novell about that then - I'm sure they'll be > pleased to be told that the form on the front page of their website > (which comes and goes - might need a few refreshes) is illegal, or > that they can't require registration to download SLED and other > products. I guess they just don't spend enough on their lawyers. > > http://www.suse.de/ Apple "fish for addresses" too on their German site, except their download doesn't happen automatically: http://www.apple.com/de/itunes/download/ -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Fri, Feb 25, 2011 at 4:23 AM, Susanne Ebrecht <miracee(at)web(dot)de> wrote: > Hello Robert, > > On 25.02.2011 03:57, Robert Haas wrote: >> >> company to take this approach. For example, Adobe does exactly the >> same thing when you download Adobe Reader. > > FYI: that is totally wrong. Adobe not even shows a register page. > I just tested. When you say something is totally wrong, you imply that I should have known better than to make the statement in the first place. But in fact, I tested it too, and at least from my computer, it is not totally wrong, but 100% correct. When I Google Adobe Reader, I get this link: http://get.adobe.com/reader/ That page has a yellow-orange box on it that says "Download Now". When I click on that page, I get a yellow box that says "Thank you. Your download will start automatically. If it does not start, click here to download. If a dialog box appears with the option to run or save, click run." Below that, it says "Register Adobe Reader. Receive up-to-date information about new releases and security updates by registering your copy of Adobe Reader." That is quite similar to what happens on the EnterpriseDB site - when you click the button to download the particular installer you want, the download starts automatically and you get prompted to register. > I think the discussion came up - because we have to deal here with > culture differences - between some European countries and US / UK. I think it is important to be clear about whether we are talking about a legal difference or a cultural difference. At least here, saying that someone is or may be breaking the law is a very serious accusation which shouldn't be made without convincing evidence. To my way of thinking, saying that a web site may be breaking an unspecified law in an unspecified European country doesn't meet that standard. Which country? Which law? If we're only talking about a cultural difference, that's another matter altogether. I'm certainly not going to argue that everyone in the world *likes* that registration page; I'm pretty sure that's not even true of everyone who works at EnterpriseDB. Certainly, to the extent that the page turns people off, that's bad for EnterpriseDB *and* the community. To the extent that the community wants to have installers of similar quality to the ones that EnterpriseDB produces without any associated commercial speech, that's going to take some significant funding which the community doesn't currently have. Personally, I think our efforts would be better spent elsewhere. I care a lot more about whether PostgreSQL gets index-only scans and global temporary tables and timely security fixes and a multi-threaded background writer than I do about whether some link on our download page goes to EnterpriseDB. If we actually had the budget to hire five people to work on PostgreSQL full-time, I'd pay them to do that stuff, not this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Josh Berkus said in another thread: > Back in 2007, at Sun I hired an industry analyst to do research give me > a list of the 5 biggest items inhibiting PostgreSQL community growth and > large enterprise adoption. The lack of "all-in-one packages" was item > #3. The fact that EnterpriseDB eliminated that item has expanded our > community and user base to many people who never tried PostgreSQL before. So refresh us again what the top five were? - -- Greg Sabino Mullane greg(at)turnstep(dot)com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201102252310 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1ofVAACgkQvJuQZxSWSsjuWwCeIiBRjuQR6VxDOIwMO7fNkNe5 QRYAnR+tJ1MN7fQ1s/NYauE5jE5DlzO7 =Gw8V -----END PGP SIGNATURE-----
On Fri, Feb 25, 2011 at 11:11 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > Josh Berkus said in another thread: > >> Back in 2007, at Sun I hired an industry analyst to do research give me >> a list of the 5 biggest items inhibiting PostgreSQL community growth and >> large enterprise adoption. The lack of "all-in-one packages" was item >> #3. The fact that EnterpriseDB eliminated that item has expanded our >> community and user base to many people who never tried PostgreSQL before. > > So refresh us again what the top five were? > > - -- good post Greg. I meant to ask the same earlier in the day. Give it up Josh. :-) -- Mike Ellsworth
On 2/25/11 8:11 PM, Greg Sabino Mullane wrote:
>
> Josh Berkus said in another thread:
>
>> Back in 2007, at Sun I hired an industry analyst to do research give me
>> a list of the 5 biggest items inhibiting PostgreSQL community growth and
>> large enterprise adoption. The lack of "all-in-one packages" was item
>> #3. The fact that EnterpriseDB eliminated that item has expanded our
>> community and user base to many people who never tried PostgreSQL before.
>
> So refresh us again what the top five were?
Well, it's with the minutes of the 2007 developer meeting ... *if*
anyone can find that on the wiki. Someday we need to fix wiki search.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
> Well, it's with the minutes of the 2007 developer meeting ... *if*
> anyone can find that on the wiki. Someday we need to fix wiki search.
Aha found it, no thanks to wiki search, and no thanks to Spotlight either.
So, my memory was wrong. Actually, they reported having a one-click
install as the #1 issue, not the #3 issue:
1. Easy Install
2. Simple, low-overhead replication
3. Upgrade-in-place
4. Administration & monitoring
5. Driver quality/maintenance
... it's really nice the number of the above issues we've knocked out
since 2007.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, Feb 26, 2011 at 1:39 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote: > >> Well, it's with the minutes of the 2007 developer meeting ... *if* >> anyone can find that on the wiki. Someday we need to fix wiki search. > > Aha found it, no thanks to wiki search, and no thanks to Spotlight either. > > So, my memory was wrong. Actually, they reported having a one-click > install as the #1 issue, not the #3 issue: > > 1. Easy Install > > 2. Simple, low-overhead replication > > 3. Upgrade-in-place > > 4. Administration & monitoring > > 5. Driver quality/maintenance > > ... it's really nice the number of the above issues we've knocked out > since 2007. Link? :) -selena -- http://chesnok.com
>> ... it's really nice the number of the above issues we've knocked out
>> since 2007.
>
> Link? :)
What link? I *still* can't find the minutes on the wiki.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote: > >>> ... it's really nice the number of the above issues we've knocked out >>> since 2007. >> >> Link? :) > > What link? I *still* can't find the minutes on the wiki. Ah, I thought you meant that you'd found this on the wiki. I don't see any information about PgCon 2007 on the wiki, so it may not be the fault of search. -selena -- http://chesnok.com
On 2/26/11 1:51 PM, Selena Deckelmann wrote:
> On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>>> ... it's really nice the number of the above issues we've knocked out
>>>> since 2007.
>>> Link? :)
>> What link? I *still* can't find the minutes on the wiki.
>
> Ah, I thought you meant that you'd found this on the wiki.
>
> I don't see any information about PgCon 2007 on the wiki, so it may
> not be the fault of search.
Can't find them on my HDD either. Did we not do minutes for the first
meeting?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, Feb 26, 2011 at 1:54 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote: > On 2/26/11 1:51 PM, Selena Deckelmann wrote: >> On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote: >>>>> ... it's really nice the number of the above issues we've knocked out >>>>> since 2007. >>>> Link? :) >>> What link? I *still* can't find the minutes on the wiki. >> >> Ah, I thought you meant that you'd found this on the wiki. >> >> I don't see any information about PgCon 2007 on the wiki, so it may >> not be the fault of search. > > Can't find them on my HDD either. Did we not do minutes for the first > meeting? I wasn't there, so don't know. :) -selena -- http://chesnok.com
Josh Berkus wrote: > > > Well, it's with the minutes of the 2007 developer meeting ... *if* > > anyone can find that on the wiki. Someday we need to fix wiki search. > > Aha found it, no thanks to wiki search, and no thanks to Spotlight either. > > So, my memory was wrong. Actually, they reported having a one-click > install as the #1 issue, not the #3 issue: > > 1. Easy Install > > 2. Simple, low-overhead replication > > 3. Upgrade-in-place > > 4. Administration & monitoring > > 5. Driver quality/maintenance > > ... it's really nice the number of the above issues we've knocked out > since 2007. Wow, that is amazing, like we actually have a plan. ;-) LOL -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On lör, 2011-02-26 at 13:54 -0800, Josh Berkus wrote: > On 2/26/11 1:51 PM, Selena Deckelmann wrote: > > On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote: > >>>> ... it's really nice the number of the above issues we've knocked out > >>>> since 2007. > >>> Link? :) > >> What link? I *still* can't find the minutes on the wiki. > > > > Ah, I thought you meant that you'd found this on the wiki. > > > > I don't see any information about PgCon 2007 on the wiki, so it may > > not be the fault of search. > > Can't find them on my HDD either. Did we not do minutes for the first > meeting? Yes: http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting But what you are looking for is here: http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#Top_Adoption_Issues
> Yes: http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting > > But what you are looking for is here: > http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#Top_Adoption_Issues Was 2008 the first meeting? Huh. Yeah, I suppose so. So I must have introduced the top 5 items in an unofficial meeting in 2007, because I did so when we originally commissioned the research. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
Le 26/02/2011 22:39, Josh Berkus a écrit : > >> Well, it's with the minutes of the 2007 developer meeting ... *if* >> anyone can find that on the wiki. Someday we need to fix wiki search. > > Aha found it, no thanks to wiki search, and no thanks to Spotlight either. > > So, my memory was wrong. Actually, they reported having a one-click > install as the #1 issue, not the #3 issue: > > 1. Easy Install > > 2. Simple, low-overhead replication > > 3. Upgrade-in-place > > 4. Administration & monitoring > > 5. Driver quality/maintenance > > ... it's really nice the number of the above issues we've knocked out > since 2007. > yes... it would be interesting to know what are the 5 next challenges :) -- damien clochard dalibo.com | dalibo.org
> yes... it would be interesting to know what are the 5 next challenges :)
I don't have an analyst budget anymore. Although ...
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On 02/28/11 22:58, damien clochard wrote: > Le 26/02/2011 22:39, Josh Berkus a écrit : >> >>> Well, it's with the minutes of the 2007 developer meeting ... *if* >>> anyone can find that on the wiki. Someday we need to fix wiki search. >> >> Aha found it, no thanks to wiki search, and no thanks to Spotlight either. >> >> So, my memory was wrong. Actually, they reported having a one-click >> install as the #1 issue, not the #3 issue: >> >> 1. Easy Install >> >> 2. Simple, low-overhead replication >> >> 3. Upgrade-in-place >> >> 4. Administration & monitoring >> >> 5. Driver quality/maintenance >> >> ... it's really nice the number of the above issues we've knocked out >> since 2007. >> > > yes... it would be interesting to know what are the 5 next challenges :) 1. To get rid of nasty CSTRING type 2. To get rid of the difference between TEXT and BYTEA (and then get rid of the BYTEA) 3. To make TIMESTAMPTZ useful by introducing proper type cast TIMESTAMPTZ to TIMESTAMP 4. Introduce a pair of preferences (server_timezone, client_timezone) instead of a single pref (timezone) (and use their values similar as (client_encoding, server_encoding) are used) 5. N/A the Postrgesql is too good for me to compose 5th challenge. but these four are too disturbing and irrational. example SELECT 'epoch'::TIMESTAMP = 'epoch'::TIMESTAMPTZ::TIMESTAMP; OOPS! we have TWO DIFFERENT EPOCHS!!!
On 1 March 2011 06:39, silly sad <sad(at)bestmx(dot)ru> wrote: > On 02/28/11 22:58, damien clochard wrote: >> Le 26/02/2011 22:39, Josh Berkus a écrit : >>> >>>> Well, it's with the minutes of the 2007 developer meeting ... *if* >>>> anyone can find that on the wiki. Someday we need to fix wiki search. >>> >>> Aha found it, no thanks to wiki search, and no thanks to Spotlight either. >>> >>> So, my memory was wrong. Actually, they reported having a one-click >>> install as the #1 issue, not the #3 issue: >>> >>> 1. Easy Install >>> >>> 2. Simple, low-overhead replication >>> >>> 3. Upgrade-in-place >>> >>> 4. Administration & monitoring >>> >>> 5. Driver quality/maintenance >>> >>> ... it's really nice the number of the above issues we've knocked out >>> since 2007. >>> >> >> yes... it would be interesting to know what are the 5 next challenges :) > > 1. To get rid of nasty CSTRING type > 2. To get rid of the difference between TEXT and BYTEA (and then get rid > of the BYTEA) > 3. To make TIMESTAMPTZ useful by introducing proper type cast > TIMESTAMPTZ to TIMESTAMP > 4. Introduce a pair of preferences (server_timezone, client_timezone) > instead of a single pref (timezone) (and use their values similar as > (client_encoding, server_encoding) are used) > 5. N/A > > the Postrgesql is too good for me to compose 5th challenge. > but these four are too disturbing and irrational. > > example > > SELECT 'epoch'::TIMESTAMP = 'epoch'::TIMESTAMPTZ::TIMESTAMP; > > OOPS! we have TWO DIFFERENT EPOCHS!!! No, you have one which doesn't apply the timezone difference, and one which does. So if you're UTC+1, you end up with: '1970-01-01 00:00:00' = '1970-01-01 01:00:00' -- false When you cast this timestamp with timezone to a normal timestamp, it retains the time, but not the timezone. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
* silly sad: > 2. To get rid of the difference between TEXT and BYTEA (and then get rid > of the BYTEA) The TEXT/BYTEA distinction is used by several interface libraries to create appropriate programming language types. What might work, though, is to get rid of BYTEA escaping in the wire protocol (optionally, for backwards compatibility), and support NUL characters in TEXT. -- Florian Weimer <fweimer(at)bfk(dot)de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Excerpts from silly sad's message of mar mar 01 03:39:35 -0300 2011: > 3. To make TIMESTAMPTZ useful by introducing proper type cast > TIMESTAMPTZ to TIMESTAMP I think this is the AT TIME ZONE operator (works both ways). > 4. Introduce a pair of preferences (server_timezone, client_timezone) > instead of a single pref (timezone) (and use their values similar as > (client_encoding, server_encoding) are used) I think server_timezone is hardwired as GMT. client_timezone is our current timezone setting. I don't see the point in having server_timezone be configurable ... is there one? -- Álvaro Herrera <alvherre(at)commandprompt(dot)com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Sad,
Thanks for the wishlist, but this doesn't seem likely to be the top
priorities of new adopters. ;-)
> 1. To get rid of nasty CSTRING type
> 2. To get rid of the difference between TEXT and BYTEA (and then get rid
> of the BYTEA)
> 3. To make TIMESTAMPTZ useful by introducing proper type cast
> TIMESTAMPTZ to TIMESTAMP
Why are you using Timestamp-no-tz at all? I was thinking we should
change the default ...
> 4. Introduce a pair of preferences (server_timezone, client_timezone)
> instead of a single pref (timezone) (and use their values similar as
> (client_encoding, server_encoding) are used)
When would server_timezone be used?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > 1. Easy Install > 2. Simple, low-overhead replication > 3. Upgrade-in-place > 4. Administration & monitoring > 5. Driver quality/maintenance >> ... it's really nice the number of the above issues we've knocked out >> since 2007. > > yes... it would be interesting to know what are the 5 next challenges :) I think we haven't finished these five yet! :) > 1. Easy Install Solved, I suppose. We've always had "yum install" and friends, and now we have the EDB 1-click installer. The only fly in the ointment is the recent crap Debian pulled (yes, what they did was correct, but it should have been handled much better). Hopefully that will be solved soon with some better (and better licensed) supporting software. So this one is done. > 2. Simple, low-overhead replication Great progress here with hot standby which satisfies a great number of replication needs with very low overhead. I would not call it "simple" yet, but there are some tools out there that are attempting to fix this. Sometimes you need more than hot standby of course, and none of Bucardo, Slony, or Londiste are simple or low overhead. To be fair, however, I wonder how simple and low overhead some of the other RDBMSs solutions are. This one is mostly done. > 3. Upgrade-in-place Big success and big fail here. pg_upgrade goes a long, long way towards something better than pg_dump|psql, but it's not a true upgrade-in-place, where I can point my Postgres X+1 at my Postgres X data directory and have it all work. We need to catch up with Oracle on this. Halfway done. > 4. Administration & monitoring This is a pretty vague and wide-ranging topic, so it's hard to address. We do have a slew of administration GUIs, and a bunch of monitoring tools, but especially the latter need some work. Would be nice if these bullet points were broken down a little further with some actual specific complaints or ideas. Any chance of that, Josh? > 5. Driver quality/maintenance Also a little vague - which drivers? Certainly most of the major languages have decent drivers now. I think the Perl one is pretty good ;). PHP and Ruby are much improved in the last few years, and the most problematic one, Python, is getting better (and finally winnowing the choices as well). The maintenance is probably still an issue. Certainly there is a very small number of people taking care of each driver, and no single company (e.g. EDB) stepping up to dedicate a group of people to the care of feeding of a driver. - -- Greg Sabino Mullane greg(at)turnstep(dot)com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201103012252 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1tv7EACgkQvJuQZxSWSsh9qwCfciRmJ2kLiHu0npG/TLyTa88N wYQAoLVNWwOBEQ1YaAUbEIucks8VKqYv =6v06 -----END PGP SIGNATURE-----
On Tue, Mar 1, 2011 at 10:55 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > >> 1. Easy Install >> 2. Simple, low-overhead replication >> 3. Upgrade-in-place >> 4. Administration & monitoring >> 5. Driver quality/maintenance > >>> ... it's really nice the number of the above issues we've knocked out >>> since 2007. >> >> yes... it would be interesting to know what are the 5 next challenges :) > > I think we haven't finished these five yet! :) > >> 1. Easy Install > > Solved, I suppose. We've always had "yum install" and friends, and now > we have the EDB 1-click installer. The only fly in the ointment is > the recent crap Debian pulled (yes, what they did was correct, but > it should have been handled much better). Hopefully that will be solved > soon with some better (and better licensed) supporting software. > So this one is done. > >> 2. Simple, low-overhead replication > > Great progress here with hot standby which satisfies a great number > of replication needs with very low overhead. I would not call it > "simple" yet, but there are some tools out there that are attempting > to fix this. Sometimes you need more than hot standby of course, and > none of Bucardo, Slony, or Londiste are simple or low overhead. To be > fair, however, I wonder how simple and low overhead some of the other > RDBMSs solutions are. This one is mostly done. > You're much more optimistic than I am about this. Most of the other databases offer built in solutions that are quite a bit more flexible than what pg offers, and I don't see any changes to that on the horizon. See Haas' recent blog post on the topic for some limitations we aren't trying to solve. I think we'll have to embrace statement based replication at some point, but I know a lot of people are pretty against the idea. >> 3. Upgrade-in-place > > Big success and big fail here. pg_upgrade goes a long, long way towards > something better than pg_dump|psql, but it's not a true upgrade-in-place, > where I can point my Postgres X+1 at my Postgres X data directory and > have it all work. We need to catch up with Oracle on this. Halfway done. > Yeah; other things like being to replicate across versions are also something a lot of people would like to see. I think it's probably technically doable, although again I don't see anyone interested in working on it. >> 4. Administration & monitoring > > This is a pretty vague and wide-ranging topic, so it's hard to address. > We do have a slew of administration GUIs, and a bunch of monitoring > tools, but especially the latter need some work. Would be nice if these > bullet points were broken down a little further with some actual > specific complaints or ideas. Any chance of that, Josh? > Yeah, I think part of the issue here is either a lack of integration with "enterprisy" tools, or no really slick GUI of our own. (With apologies to pgadmin, but people coming from things like oem or sql server manager often find it very lacking) >> 5. Driver quality/maintenance > > Also a little vague - which drivers? Certainly most of the major languages > have decent drivers now. I think the Perl one is pretty good ;). PHP > and Ruby are much improved in the last few years, and the most problematic > one, Python, is getting better (and finally winnowing the choices as well). > > The maintenance is probably still an issue. Certainly there is a very > small number of people taking care of each driver, and no single company > (e.g. EDB) stepping up to dedicate a group of people to the care of > feeding of a driver. > Yeah, I think a number of these could use someone with a more dedicated interest in keeping them up to date with the main product line. Also you left out ODBC, which afaik is still a bit hard for most people to get moving with. Robert Treat http://www.xzilla.net
On Mar 2 2011, Josh Berkus wrote: >Sad, > >Thanks for the wishlist, but this doesn't seem likely to be the top >priorities of new adopters. ;-) > >> 1. To get rid of nasty CSTRING type >> 2. To get rid of the difference between TEXT and BYTEA (and then get rid >> of the BYTEA) >> 3. To make TIMESTAMPTZ useful by introducing proper type cast >> TIMESTAMPTZ to TIMESTAMP > >Why are you using Timestamp-no-tz at all? I was thinking we should >change the default ... Why did u introduced it? >> 4. Introduce a pair of preferences (server_timezone, client_timezone) >> instead of a single pref (timezone) (and use their values similar as >> (client_encoding, server_encoding) are used) > >When would server_timezone be used? > >
On Mar 1 2011, Alvaro Herrera wrote: >Excerpts from silly sad's message of mar mar 01 03:39:35 -0300 2011: > >> 3. To make TIMESTAMPTZ useful by introducing proper type cast >> TIMESTAMPTZ to TIMESTAMP > >I think this is the AT TIME ZONE operator (works both ways). > >> 4. Introduce a pair of preferences (server_timezone, client_timezone) >> instead of a single pref (timezone) (and use their values similar as >> (client_encoding, server_encoding) are used) > >I think server_timezone is hardwired as GMT. client_timezone is our >current timezone setting. I don't see the point in having >server_timezone be configurable ... is there one? GMT? let it be. i only ask u to USE IT while casting ::TIMESTAMPTZ::TIMESTAMP (instead of dropping TZ information)
Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011: > On Mar 2 2011, Josh Berkus wrote: > >> 3. To make TIMESTAMPTZ useful by introducing proper type cast > >> TIMESTAMPTZ to TIMESTAMP > > > >Why are you using Timestamp-no-tz at all? I was thinking we should > >change the default ... > > Why did u introduced it? The standard requires the current behavior. It's not going to change. It changed in 7.1 or so. -- Álvaro Herrera <alvherre(at)commandprompt(dot)com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Excerpts from sad's message of mié mar 02 10:35:59 -0300 2011: > On Mar 1 2011, Alvaro Herrera wrote: > > >Excerpts from silly sad's message of mar mar 01 03:39:35 -0300 2011: > >I think this is the AT TIME ZONE operator (works both ways). > > > >> 4. Introduce a pair of preferences (server_timezone, client_timezone) > >> instead of a single pref (timezone) (and use their values similar as > >> (client_encoding, server_encoding) are used) > > > >I think server_timezone is hardwired as GMT. client_timezone is our > >current timezone setting. I don't see the point in having > >server_timezone be configurable ... is there one? > > GMT? let it be. > i only ask u to USE IT while casting ::TIMESTAMPTZ::TIMESTAMP > (instead of dropping TZ information) As I said in my previous response, don't cast. Use AT TIME ZONE. -- Álvaro Herrera <alvherre(at)commandprompt(dot)com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 26 February 2011 21:35, Josh Berkus <josh(at)agliodbs(dot)com> wrote: > > Someday we need to fix wiki search. > http://www.mediawiki.org/wiki/Extension:MWSearch using a Lucene-search 2.1 daemon. That is what wikipedia and us (OpenStreetMap) use. Regards Grant Part of OSM Sysadmin team.
On Wed, Mar 2, 2011 at 17:25, Grant Slater <postgresql(at)firefishy(dot)com> wrote: > On 26 February 2011 21:35, Josh Berkus <josh(at)agliodbs(dot)com> wrote: >> >> Someday we need to fix wiki search. >> > > http://www.mediawiki.org/wiki/Extension:MWSearch > using a Lucene-search 2.1 daemon. > > That is what wikipedia and us (OpenStreetMap) use. Gah, yet another piece of software :-( What do we use *now*? Does it actually use tsearch, or something else? It's not like we need lucene for performance... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 03/02/11 17:07, Alvaro Herrera wrote: > Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011: >> On Mar 2 2011, Josh Berkus wrote: > >>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast >>>> TIMESTAMPTZ to TIMESTAMP >>> >>> Why are you using Timestamp-no-tz at all? I was thinking we should >>> change the default ... >> >> Why did u introduced it? > > The standard requires the current behavior. It's not going to change. > It changed in 7.1 or so. > does standard require to have TWO DIFFERENT EPOCHS? SELECT 'epoch'::TIMESTAMPTZ, 'epoch'::TIMESTAMP;
> What do we use *now*? Does it actually use tsearch, or something else?
> It's not like we need lucene for performance...
If it's using tsearch, it's not creating the index correctly. Searches
on words which are *all over* a page don't turn up that page.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >>On 26 February 2011 21:35, Josh Berkus <josh(at)agliodbs(dot)com> wrote: >> >> Someday we need to fix wiki search. > > http://www.mediawiki.org/wiki/Extension:MWSearch > using a Lucene-search 2.1 daemon. > > That is what wikipedia and us (OpenStreetMap) use. What exactly is broken about it? From what I recall, Josh's search failed because the page did not exist (no notes put on wiki from the 2007 meeting). If there is a problem, I'd rather continue to eat our own tsearch dogfood and fix it rather than go with yet another piece of technology. - -- Greg Sabino Mullane greg(at)turnstep(dot)com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201103032222 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1wWwsACgkQvJuQZxSWSsjE+wCglkbPzLA6SS9FYKEL2tLaK0eU 0IkAoKYTpiajC+pvbCPFw+Lb8Jr2pxmj =JK1X -----END PGP SIGNATURE-----
Robert Treat wrote: > >> 2. Simple, low-overhead replication > > > > Great progress here with hot standby which satisfies a great number > > of replication needs with very low overhead. I would not call it > > "simple" yet, but there are some tools out there that are attempting > > to fix this. Sometimes you need more than hot standby of course, and > > none of Bucardo, Slony, or Londiste are simple or low overhead. To be > > fair, however, I wonder how simple and low overhead some of the other > > RDBMSs solutions are. This one is mostly done. > > > > You're much more optimistic than I am about this. Most of the other > databases offer built in solutions that are quite a bit more flexible > than what pg offers, and I don't see any changes to that on the > horizon. See Haas' recent blog post on the topic for some limitations > we aren't trying to solve. I think we'll have to embrace statement > based replication at some point, but I know a lot of people are pretty > against the idea. I hope people are not confusing logical row replication with statement-based (SQL query) replication. Robert was talking about the former, and the later is fraught with problems. -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Alvaro Herrera wrote: > Excerpts from sad's message of mi mar 02 10:23:53 -0300 2011: > > On Mar 2 2011, Josh Berkus wrote: > > > >> 3. To make TIMESTAMPTZ useful by introducing proper type cast > > >> TIMESTAMPTZ to TIMESTAMP > > > > > >Why are you using Timestamp-no-tz at all? I was thinking we should > > >change the default ... > > > > Why did u introduced it? > > The standard requires the current behavior. It's not going to change. > It changed in 7.1 or so. And we document why the default is so odd: http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES Note: The SQL standard requires that writing just timestamp be equivalent to timestamp without time zone, and PostgreSQL honors that behavior. (Releases prior to 7.3 treated it as timestamp with time zone.) -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
silly sad wrote: > On 03/10/11 19:01, Bruce Momjian wrote: > > Alvaro Herrera wrote: > >> Excerpts from sad's message of mi? mar 02 10:23:53 -0300 2011: > >>> On Mar 2 2011, Josh Berkus wrote: > >> > >>>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast > >>>>> TIMESTAMPTZ to TIMESTAMP > >>>> > >>>> Why are you using Timestamp-no-tz at all? I was thinking we should > >>>> change the default ... > >>> > >>> Why did u introduced it? > >> > >> The standard requires the current behavior. It's not going to change. > >> It changed in 7.1 or so. > > > > And we document why the default is so odd: > > > > http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES > > > > Note: The SQL standard requires that writing just timestamp be > > equivalent to timestamp without time zone, and PostgreSQL honors that > > behavior. (Releases prior to 7.3 treated it as timestamp with time > > zone.) > > do you document why 'epoch'::timestamp is not the true 'epoch' unless > timezone is not GMT? > > if you mention any timestamp except 'epoch' it will be interpreted > correctly taking in account timezone setting. Well, 'epoch' clearly is a point in time with the hour being midnight at GMT, so I don't see a problem with epoch making such an adjustment: test=> select 'epoch'::timestamp ; timestamp --------------------- 1970-01-01 00:00:00 (1 row) test=> select 'epoch'::timestamptz; timestamptz ------------------------ 1969-12-31 19:00:00-05 (1 row) However, a text string behaves the same: test=> select '1970-01-01 00:00:00'::timestamp; timestamp --------------------- 1970-01-01 00:00:00 (1 row) test=> select '1970-01-01 00:00:00'::timestamptz; timestamptz ------------------------ 1970-01-01 00:00:00-05 (1 row) Notice the "-05". I would argue that 'epoch' has a predefined timezone. We don't document this because it has never been mentioned before and no one has mentioned they were surprised by the behavior. -- Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 03/10/11 19:01, Bruce Momjian wrote: > Alvaro Herrera wrote: >> Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011: >>> On Mar 2 2011, Josh Berkus wrote: >> >>>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast >>>>> TIMESTAMPTZ to TIMESTAMP >>>> >>>> Why are you using Timestamp-no-tz at all? I was thinking we should >>>> change the default ... >>> >>> Why did u introduced it? >> >> The standard requires the current behavior. It's not going to change. >> It changed in 7.1 or so. > > And we document why the default is so odd: > > http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES > > Note: The SQL standard requires that writing just timestamp be > equivalent to timestamp without time zone, and PostgreSQL honors that > behavior. (Releases prior to 7.3 treated it as timestamp with time > zone.) do you document why 'epoch'::timestamp is not the true 'epoch' unless timezone is not GMT? if you mention any timestamp except 'epoch' it will be interpreted correctly taking in account timezone setting.
On 03/10/11 19:45, Bruce Momjian wrote: > silly sad wrote: >> On 03/10/11 19:01, Bruce Momjian wrote: >>> Alvaro Herrera wrote: >>>> Excerpts from sad's message of mi? mar 02 10:23:53 -0300 2011: >>>>> On Mar 2 2011, Josh Berkus wrote: >>>> >>>>>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast >>>>>>> TIMESTAMPTZ to TIMESTAMP >>>>>> >>>>>> Why are you using Timestamp-no-tz at all? I was thinking we should >>>>>> change the default ... >>>>> >>>>> Why did u introduced it? >>>> >>>> The standard requires the current behavior. It's not going to change. >>>> It changed in 7.1 or so. >>> >>> And we document why the default is so odd: >>> >>> http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES >>> >>> Note: The SQL standard requires that writing just timestamp be >>> equivalent to timestamp without time zone, and PostgreSQL honors that >>> behavior. (Releases prior to 7.3 treated it as timestamp with time >>> zone.) >> >> do you document why 'epoch'::timestamp is not the true 'epoch' unless >> timezone is not GMT? >> >> if you mention any timestamp except 'epoch' it will be interpreted >> correctly taking in account timezone setting. > > Well, 'epoch' clearly is a point in time with the hour being midnight at > GMT, so I don't see a problem with epoch making such an adjustment: great! the flexible epoch! when do want to point an epoch to? just set timezone and enjoy.
On 03/10/2011 08:53 AM, silly sad wrote: >> >> Well, 'epoch' clearly is a point in time with the hour being midnight at >> GMT, so I don't see a problem with epoch making such an adjustment: > > > great! the flexible epoch! > > when do want to point an epoch to? > just set timezone and enjoy. > I am not sure what your point is. The epoch being used is just one of many that could have been used, see link below. So by definition the term epoch is flexible. The Postgres project has chosen a particular value for 'epoch' as explained in the docs. This 'epoch' is a special datetime value pinned to a point in time(as Bruce mentioned). All adding a time zone does is translate the GMT point in time to the time zone point in time. They are the same time. http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Computing -- Adrian Klaver adrian(dot)klaver(at)gmail(dot)com
On 03/10/11 20:07, Adrian Klaver wrote:
> On 03/10/2011 08:53 AM, silly sad wrote:
>
>
>>>
>>> Well, 'epoch' clearly is a point in time with the hour being midnight at
>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>
>>
>> great! the flexible epoch!
>>
>> when do want to point an epoch to?
>> just set timezone and enjoy.
>>
>
> I am not sure what your point is.
my point is:
SELECT extract('epoch' from 'epoch'::timestamp);
On 03/10/2011 09:15 AM, silly sad wrote:
> On 03/10/11 20:07, Adrian Klaver wrote:
>> On 03/10/2011 08:53 AM, silly sad wrote:
>>
>>
>>>>
>>>> Well, 'epoch' clearly is a point in time with the hour being midnight at
>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>
>>>
>>> great! the flexible epoch!
>>>
>>> when do want to point an epoch to?
>>> just set timezone and enjoy.
>>>
>>
>> I am not sure what your point is.
>
> my point is:
>
> SELECT extract('epoch' from 'epoch'::timestamp);
Simplest explanation is you are comparing a time zone aware datetime
'epoch' to an unaware one 'epoch'::timezone. The second one, since it
is not anchored to a time zone is taken to be local time and the result
you get is the interval in seconds between the two.
Try:
test=> SELECT extract(EPOCH from 'epoch'::timestamptz);
date_part
-----------
0
or
test=> SELECT extract(EPOCH from 'epoch'::timestamp at time zone 'utc');
date_part
-----------
0
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
On 03/10/2011 09:57 AM, silly sad wrote:
> On 03/10/11 20:48, Adrian Klaver wrote:
>> On 03/10/2011 09:15 AM, silly sad wrote:
>>> On 03/10/11 20:07, Adrian Klaver wrote:
>>>> On 03/10/2011 08:53 AM, silly sad wrote:
>>>>
>>>>
>>>>>>
>>>>>> Well, 'epoch' clearly is a point in time with the hour being
>>>>>> midnight at
>>>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>>>
>>>>>
>>>>> great! the flexible epoch!
>>>>>
>>>>> when do want to point an epoch to?
>>>>> just set timezone and enjoy.
>>>>>
>>>>
>>>> I am not sure what your point is.
>>>
>>> my point is:
>>>
>>> SELECT extract('epoch' from 'epoch'::timestamp);
>>
>> Simplest explanation is you are comparing a time zone aware datetime
>> 'epoch' to an unaware one 'epoch'::timezone. The second one, since it
>> is not anchored to a time zone is taken to be local time and the result
>> you get is the interval in seconds between the two.
>
> (1) do u really believe in this?
> (2) why didn't u try the select i wrote?
Yes
I did.
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
On 03/10/11 20:48, Adrian Klaver wrote:
> On 03/10/2011 09:15 AM, silly sad wrote:
>> On 03/10/11 20:07, Adrian Klaver wrote:
>>> On 03/10/2011 08:53 AM, silly sad wrote:
>>>
>>>
>>>>>
>>>>> Well, 'epoch' clearly is a point in time with the hour being
>>>>> midnight at
>>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>>
>>>>
>>>> great! the flexible epoch!
>>>>
>>>> when do want to point an epoch to?
>>>> just set timezone and enjoy.
>>>>
>>>
>>> I am not sure what your point is.
>>
>> my point is:
>>
>> SELECT extract('epoch' from 'epoch'::timestamp);
>
> Simplest explanation is you are comparing a time zone aware datetime
> 'epoch' to an unaware one 'epoch'::timezone. The second one, since it
> is not anchored to a time zone is taken to be local time and the result
> you get is the interval in seconds between the two.
(1) do u really believe in this?
(2) why didn't u try the select i wrote?
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > (1) do u really believe in this? > (2) why didn't u try the select i wrote? Can we take this to -general please? Or better yet, let the thread die? - -- Greg Sabino Mullane greg(at)turnstep(dot)com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201103101307 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk15E2AACgkQvJuQZxSWSsgN0ACgm3eNwlXP+63vRx74mIk9RY6s rdUAn1lUknijWxxP0S7cANoKldTVEhPq =F24a -----END PGP SIGNATURE-----
On 03/10/11 20:52, Adrian Klaver wrote:
> On 03/10/2011 09:57 AM, silly sad wrote:
>> On 03/10/11 20:48, Adrian Klaver wrote:
>>> On 03/10/2011 09:15 AM, silly sad wrote:
>>>> On 03/10/11 20:07, Adrian Klaver wrote:
>>>>> On 03/10/2011 08:53 AM, silly sad wrote:
>>>>>
>>>>>
>>>>>>>
>>>>>>> Well, 'epoch' clearly is a point in time with the hour being
>>>>>>> midnight at
>>>>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>>>>
>>>>>>
>>>>>> great! the flexible epoch!
>>>>>>
>>>>>> when do want to point an epoch to?
>>>>>> just set timezone and enjoy.
>>>>>>
>>>>>
>>>>> I am not sure what your point is.
>>>>
>>>> my point is:
>>>>
>>>> SELECT extract('epoch' from 'epoch'::timestamp);
>>>
>>> Simplest explanation is you are comparing a time zone aware datetime
>>> 'epoch' to an unaware one 'epoch'::timezone. The second one, since it
>>> is not anchored to a time zone is taken to be local time and the result
>>> you get is the interval in seconds between the two.
>>
>> (1) do u really believe in this?
>> (2) why didn't u try the select i wrote?
>
> Yes
> I did.
do u think the 'epoch' of 'epoch' should not be 0 ?