
> When all is said and done, I think the PostgreSQL project lacks a "Product
> Management" group which steers the public perception and defines
> usability. This is something *all* other systems have, including MySQL.

Well, NO, not a chance.   

As one of the de-facto heads of our Advocacy group, let me say "you've got to 
be kidding."

MySQL is a private closed-shop software manufacturer who uses the GPL as one 
of their methods of distribution.  They are not a "real" open source project 
-- they are a private, commercial, for-profit software company.

We are not.   We are a open, 100% voluntary community of contributing 
developers and support volunteers.   Nobody is going to take orders from a 
"Product Manager", that's a position for paid software products departments.   
It would be horribly inappropriate for PostgreSQL, and would destroy 
everything that has made us successful to date.  You can't give orders to 
volunteers.   

You're statement that "all other systems" have a Product Manager is also 
wildly inaccurate.  I think you're thinking of MySQL and Mozilla only.   
Heck, even OpenOffice.org doesn't have a Product Manager, and that is a 
Sun-sponsored project.  Let alone, say, emacs.  Or Linux.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Mon, 26 Apr 2004 10:19:31 -0700
Josh Berkus <josh@agliodbs.com>
Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
Shachar,

I've been giving this some more thought.  Here are my contributions:

> 1. Setting should be on a per-database level. A per-server option is not
> good enough, and a per-session option is too difficult to implement,
> with no apparent justifiable return.

I disagree with this.  I think doing case-folding per database would be 
preposterously difficult, and that per-server is adequate.   Per database 
settings bring up a whole raft of logical conflicts, particularly around the 
system catalogs and dblink, that aren't necessarily worth navigating.

I also didn't follow the discussion of why a client-side implementation was 
technically impossible; this seems like the most obvious course to me, and to 
have *considerable* benefit.    It's also consistent with our other statement 
variables, such as datestyle, which are all client-side, per-session 
settings.   

A server-side implementation would possibly reqire touching every single 
source code file in Postgres, something that would justify a lot of effort to 
avoid.

> 2. Old applications already working with PG's lowercase folding should
> have an option to continue working unmodified for the foreseeable future.

Si.

> 1. Tri-state. Folder upper, if failes, fold lower, if succeeds, warn.

Can't see this being possible.

> 2. Dual state. Fold lower or upper. Break if client is broken.

Best, I think.  But it should be client-side.

> 3. Create a database conversion tool to change existing case.

No thanks.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Mon, 26 Apr 2004 10:51:28 -0700
Josh Berkus <josh@agliodbs.com>
Re: Bringing PostgreSQL torwards the standard regarding case folding
>
>> When all is said and done, I think the PostgreSQL project lacks a
>> "Product
>> Management" group which steers the public perception and defines
>> usability. This is something *all* other systems have, including MySQL.
>
> Well, NO, not a chance.
>
> As one of the de-facto heads of our Advocacy group, let me say "you've got
> to
> be kidding."

I don't think so, let me explain below.

>
> MySQL is a private closed-shop software manufacturer who uses the GPL as
> one
> of their methods of distribution.  They are not a "real" open source
> project
> -- they are a private, commercial, for-profit software company.

I agree, I don't like MySQL all that much.

>
> We are not.   We are a open, 100% voluntary community of contributing
> developers and support volunteers.   Nobody is going to take orders from a
> "Product Manager", that's a position for paid software products
> departments.
> It would be horribly inappropriate for PostgreSQL, and would destroy
> everything that has made us successful to date.  You can't give orders to
> volunteers.

It depends on the volunteers. Some are useless at taking orders, this is
true, others, however, are very welcoming to direction. It depends in the
individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
PostgreSQL. If a real case can be made for a feature, I'm sure they are
reasonable enough to see that and grudgingly implement it. Someone,
however, has to keep an eye on that ball.

>
> You're statement that "all other systems" have a Product Manager is also
> wildly inaccurate.  I think you're thinking of MySQL and Mozilla only.
> Heck, even OpenOffice.org doesn't have a Product Manager, and that is a
> Sun-sponsored project.  Let alone, say, emacs.  Or Linux.

Linux has Linus, he has a very good eye in the market forces. Emacs, is a
non-entity outside UNIX hard core UNIX guys. OpenOffice is very much
managed by Sun.

Mon, 26 Apr 2004 14:42:10 -0400 (EDT)
pgsql@mohawksoft.com
Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
Hey,

First of all, who is this?   I don't recognize the e-mail, and you haven't 
been signing any of your posts.

> true, others, however, are very welcoming to direction.

AFAIK, this includes none of our major code contributors.   So all you're 
really talking about is manipulating the TODO list.  You can't tell 
programmers what to code unless you're paying them.

> It depends in the
> individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
> PostgreSQL. If a real case can be made for a feature, I'm sure they are
> reasonable enough to see that and grudgingly implement it. Someone,
> however, has to keep an eye on that ball.

Yes, but they don't need  a title to do so.   Nor is there any reason for this 
to be one person.  In fact, you've just described one of the reason for the 
Core's existance -- and even the Core defers to the consensus of decision on 
this forum about which features to implement and how.

Now, if you're arguing that we could use a more cohesive, readable roadmap?  
Sure!   Want to prepare one?  I can even help you find out what's under 
development and what's not likely any time soon.

> Linux has Linus, he has a very good eye in the market forces.

Uh-huh.   So?   That still doesn't make him a "product manager".

> OpenOffice is very much
> managed by Sun.

I used to be a Project Lead for OpenOffice.org.   I think the amount of 
consensus and compromise, and the extent to which the Community Council and 
the Project Leads govern the project, would surprise you.

Overall, I've not seen you present any coherent arguments as to:
1) why we need a new person with a title for marketing stuff;
2) what this person would be doing that's not already covered by existing 
groups;
3) how this person would be able to accomplish their "job"; and
4) who this person would be.

As far as I'm concerned, we need use titles here only if it lends the entitled 
some kind of authority with the outside world that helps them on their 
volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a 
good example of a good use of titles -- that one convinces companies that he 
approaches about case studies that he's for real).   Titles are not at all 
useful *inside* the community, we don't need them.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Mon, 26 Apr 2004 12:00:09 -0700
Josh Berkus <josh@agliodbs.com>
Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
> Hey,
>
> First of all, who is this?   I don't recognize the e-mail, and you haven't
> been signing any of your posts.

I've been posting on hackers on and off for a few years. My name is Mark.
>
>> true, others, however, are very welcoming to direction.
>
> AFAIK, this includes none of our major code contributors.   So all you're
> really talking about is manipulating the TODO list.  You can't tell
> programmers what to code unless you're paying them.

Yes and no. People can and do what's needed when it is clearly
articulated. What is lacking is a clear direction WRT marketing.

>
>> It depends in the
>> individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
>> PostgreSQL. If a real case can be made for a feature, I'm sure they are
>> reasonable enough to see that and grudgingly implement it. Someone,
>> however, has to keep an eye on that ball.
>
> Yes, but they don't need  a title to do so.   Nor is there any reason for
> this
> to be one person.  In fact, you've just described one of the reason for
> the
> Core's existance -- and even the Core defers to the consensus of decision
> on
> this forum about which features to implement and how.

I think I am talking about something different. In a company, the core
team would be the CTO. I think some entity, one or more people, needs to
define the product. Typically this is marketing and product management.

>
> Now, if you're arguing that we could use a more cohesive, readable
> roadmap?
> Sure!   Want to prepare one?  I can even help you find out what's under
> development and what's not likely any time soon.

Absolutely, but it would be meaningless if no body listens.

>
>> Linux has Linus, he has a very good eye in the market forces.
>
> Uh-huh.   So?   That still doesn't make him a "product manager".

Maybe I've overstated my case, by management I mean the small 'm' not the
big 'M'

>
>> OpenOffice is very much
>> managed by Sun.
>
> I used to be a Project Lead for OpenOffice.org.

Very cool. It is a great project/product.

> I think the amount of
> consensus and compromise, and the extent to which the Community Council
> and
> the Project Leads govern the project, would surprise you.

No it wouldn't.

>
> Overall, I've not seen you present any coherent arguments as to:
> 1) why we need a new person with a title for marketing stuff;

The why is that there is no real entity doing so.

> 2) what this person would be doing that's not already covered by existing
> groups;

All the groups, with the exception of advocacy, are "here's what we are
building" and "here's a bug" groups. There is planning on hackers, but it
is almost purely technical. Marketing features do no often get a
reasonable hearing.

> 3) how this person would be able to accomplish their "job";
I think that a talented manager could make the case for certain features.

> 4) who this person would be.
We recrute like a company does.

>
> As far as I'm concerned, we need use titles here only if it lends the
> entitled
> some kind of authority with the outside world that helps them on their
> volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a
> good example of a good use of titles -- that one convinces companies that
> he
> approaches about case studies that he's for real).   Titles are not at all
> useful *inside* the community, we don't need them.

I'm not trying to change the dynamic significantly, but I think, again if
increasing usership is important, that some market driven lessons need to
be  learned.


Mon, 26 Apr 2004 15:41:25 -0400 (EDT)
pgsql@mohawksoft.com
Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
Hi, Mark,

Yes, I've seen your e-mails around.   You should use a sig, though, they're 
easy to create.

> I think I am talking about something different. In a company, the core
> team would be the CTO. I think some entity, one or more people, needs to
> define the product. Typically this is marketing and product management.

But, as Peter reminds me all the time, we're not a company.  ;-)

> The why is that there is no real entity doing so.
> 
> > 2) what this person would be doing that's not already covered by existing
> > groups;
> 
> All the groups, with the exception of advocacy, are "here's what we are
> building" and "here's a bug" groups. There is planning on hackers, but it
> is almost purely technical. Marketing features do no often get a
> reasonable hearing.

That's not an argument for not using existing apparatus.  What you've 
persuaded me is that you should:
a) join the Advocacy group;
b) galvanize people around developing a coherent marketing plan;
c) Lead a crew of volunteers and follow through on that process until the plan 
is ready for comments by Core and Hackers, 
d) stick around for the arguments and revisions

That's what we *need*.   We don't need a volunteer with a title who might or 
might not do any of the above.

I'm particulary struck by the fact that you chose to inaugurate this 
discussion on Hackers, instead of Advocacy where it would have been more 
appropriate and where more of the *existing* marketing volunteers would have 
participated.  At this point, I'd have to forward the whole thing to transfer 
it ...

> I think that a talented manager could make the case for certain features.

So?   So could any community member with a good grasp of database engineering 
and an ability to write persuasive e-mails.

> > 4) who this person would be.
> We recrute like a company does.

Um, and pay them with what?   Cowrie shells?

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Mon, 26 Apr 2004 12:47:11 -0700
Josh Berkus <josh@agliodbs.com>
Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
Josh Berkus wrote:

>I also didn't follow the discussion of why a client-side implementation was 
>technically impossible; this seems like the most obvious course to me, and to 
>have *considerable* benefit.    It's also consistent with our other statement 
>variables, such as datestyle, which are all client-side, per-session 
>settings.   
>  
>
But they are not client side, are they? The date is formatted by the 
server. The client is simply receiving whatever datestyle itselected. 
That is, assuming I understand the behaviour correctly.

I would catagorize it as a server side per-session configuration. If 
that's what you mean, we thought it was too insane because it doesn't 
explain how you are supposed to handle all the catalog and other stuff 
where you are implictly assuming quoting is not necessary.

I'l reiterate the example. Do you really expect to have to write
select "upper"("field") from "table"
and should it be "upper" or "UPPER"?

>A server-side implementation would possibly reqire touching every single 
>source code file in Postgres, something that would justify a lot of effort to 
>avoid.
>  
>
I think the concensus was that the runtime part was aprox. four lines 
where the case folding currently takes place. Obviously, you would have 
to get a var, and propogate that var to that place, but not actually 
change program flow.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/


Tue, 27 Apr 2004 00:19:08 +0300
Shachar Shemesh <psql@shemesh.biz>
Re: Bringing PostgreSQL torwards the standard regarding case folding
Shachar,

> I think the concensus was that the runtime part was aprox. four lines 
> where the case folding currently takes place. Obviously, you would have 
> to get a var, and propogate that var to that place, but not actually 
> change program flow.

That's only if you ignore the system catalogs entirely, which maybe you're 
prepared to do.  If you want to change case folding for the system catalogs, 
though, you'll need to update code in thousands of places, becuase the 
back-end code is expecting lower-case identifiers ....

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Mon, 26 Apr 2004 14:27:32 -0700
Josh Berkus <josh@agliodbs.com>
Re: Bringing PostgreSQL torwards the standard regarding case folding
Josh Berkus wrote:

>Shachar,
>
>  
>
>>I think the concensus was that the runtime part was aprox. four lines 
>>where the case folding currently takes place. Obviously, you would have 
>>to get a var, and propogate that var to that place, but not actually 
>>change program flow.
>>    
>>
>
>That's only if you ignore the system catalogs entirely, which maybe you're 
>prepared to do.  If you want to change case folding for the system catalogs, 
>though, you'll need to update code in thousands of places, becuase the 
>back-end code is expecting lower-case identifiers ....
>
>  
>
IF you want per session setting, yes.

If you want per database setting, you only need to worry about the 
shared catalogs

If you want server wide setting, you just create the catalogs with the 
correct name, and get it over with.

That's why I said that per-session setting seems like too much trouble.

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/


Tue, 27 Apr 2004 00:33:30 +0300
Shachar Shemesh <psql@shemesh.biz>
Re: Bringing PostgreSQL torwards the standard regarding case folding
On Mon, 26 Apr 2004, Josh Berkus wrote:

> Shachar,
> 
> > I think the concensus was that the runtime part was aprox. four lines 
> > where the case folding currently takes place. Obviously, you would have 
> > to get a var, and propogate that var to that place, but not actually 
> > change program flow.
> 
> That's only if you ignore the system catalogs entirely, which maybe you're 
> prepared to do.  If you want to change case folding for the system catalogs, 
> though, you'll need to update code in thousands of places, becuase the 
> back-end code is expecting lower-case identifiers ....

As someone who has discussed this with Tom in the past, I seem to remember 
that there were major issues with handling the system catalogs, because 
internally, the backends treat the identifiers as if they have already 
been quoted.

I think the answer to all of this would require a lot of code being 
touched to either make it case fold, costing performance, or the 
replacement of the default lower cased catalog with upper cased catalog.

i.e. no simple switch setting, but an initdb option that would be set like 
locale currently is, for the life of the cluster.

A more comprehensive solution, one which allowed switching from upper 
folding to lower folding to no folding, to case insensitive, or some 
subset of those possibilities results in 

a:  slower backend performance, due to folding case for system catalogs
b:  touching a helluva lot of backend code to make it possible to fold up 
or down.

I'm not 100% sure on this all, but that seems to be the point Tom and I 
came to in our discussion, and neither of the two solutions seemed very 
good at the time.


Tue, 27 Apr 2004 11:43:54 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Bringing PostgreSQL torwards the standard regarding
On Mon, 26 Apr 2004, Josh Berkus wrote:

> > I think that a talented manager could make the case for certain features.
> 
> So?   So could any community member with a good grasp of database engineering 
> and an ability to write persuasive e-mails.

I'd like to inject here that I was the one who started the whole argument 
over date style enforcement about a year ago.  It was a bit of a slog at 
first, but I felt my input was good, and the cause was just :-).

Because of that discussion, PostgreSQL accpeting dates like

2004-31-03 and turning them into 2004-03-31 on the fly stopped.  as did 
postgresql accepting a date like 03/31/2004 and turning it into 31/03/2004 
when it was set to accept Euro style dates.

I am not a PostgreSQL hacker, just a user.  My input made the difference.  
No title needed.  What PostgreSQL needs more of is caring users who can 
spot bugs / misbehaviours, make a decent argument about it, and maybe even 
a patch or two.  We're way more short on indians than chiefs in my 
opinion.


Tue, 27 Apr 2004 11:55:42 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
scott.marlowe wrote:

>I think the answer to all of this would require a lot of code being 
>touched to either make it case fold, costing performance, or the 
>replacement of the default lower cased catalog with upper cased catalog.
>  
>
I'm not the one to decide, but it seems to me that this is not a good 
time to enter such a major change, and may never be. How terrible will 
it be if the system is per server (i.e. - one given to initdb?).

>A more comprehensive solution, one which allowed switching from upper 
>folding to lower folding to no folding, to case insensitive, or some 
>subset of those possibilities results in 
>
>a:  slower backend performance, due to folding case for system catalogs
>b:  touching a helluva lot of backend code to make it possible to fold up 
>or down.
>  
>
Well, if it's only the shared catalogs that are affected, this may not 
be such a big problem (very hopeful tone?)

>I'm not 100% sure on this all, but that seems to be the point Tom and I 
>came to in our discussion, and neither of the two solutions seemed very 
>good at the time.
>  
>
       Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/


Tue, 27 Apr 2004 20:59:29 +0300
Shachar Shemesh <psql@shemesh.biz>
Re: Bringing PostgreSQL torwards the standard regarding
scott.marlowe kirjutas T, 27.04.2004 kell 20:43:

> As someone who has discussed this with Tom in the past, I seem to remember 
> that there were major issues with handling the system catalogs, because 
> internally, the backends treat the identifiers as if they have already 
> been quoted.

why not leave it at that and mandate their *external* doublequoted use ?

not only for system catalogs but also for system columns.

I already have had negative experience with a proprietary tool not being
able to use postgres (over ODBC) because it has a system column called
tmin (or was it tid). If things were case-folded to upper automatically,
there would not have been such problem.

--------------
Hannu


Wed, 28 Apr 2004 11:31:57 +0300
Hannu Krosing <hannu@tm.ee>
Re: Bringing PostgreSQL torwards the standard regarding