Re: Top five challenges

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 ?