Search Postgresql Archives

Re: Please change default characterset for database cluster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 28 Sep 2007 21:32:43 -0400, "Carlos Moreno"
<moreno_pg@xxxxxxxxxxx> said:
> CN wrote:
> > Hi!
> > "initdb" use SQL_ASCII as the default characterset encoding when it is
> > not given option "-E" and when it can not correctly derive one from
> > locale. I suggest "initdb" use UNICODE instead of SQL_ASCII because
> > UNICODE is far more useful than SQL_ASCII.
> >
> 
> In addition to the general comment that the world does not necessarily
> revolve around you, and that you should not expect all software products
> in the world to be customized to suit *your* needs, I have to highlight
> how horrifying this is:
> 
> > Not all webmasters are willing to spend time reading "initdb"
> > documentation.
> This is truly horrifying --- well, fortunately, one could hope that it
> is as wrong as the rest of your message; that dumb and lazy end users
> and computer illiterate people are not willing to spend time reading
> documentation or instructions is ok... But webmasters and database
> administrators??? Do you *seriously* expect that some highly complex
> software like a DB server should be handled by people who are not
> willing to read documentation???? That's the most preposterous notion
> I've read in the last few months!
> 
> Another detail to add --- for a lot of people, Unicode is a useless
> feature that has a very important performance hit. For a *very large*
> fraction of applications, I see it generally advised to use a database
> with no encoding (which SQL_ASCII essentially is), and in the situations
> where some locale-aware processing is needed, then the client
> application can do it.
> 
> Of course, there are also many many applications where a DB with
> Unicode encoding is very useful. In those cases, the administrators
> can create a database with Unicode encoding (you seem to be one of
> those that are too busy to be willing to spend time reading the
> documentation of *createdb*), regardless of what default encoding was
> specified with initdb.
> 
> Oh, and BTW, welcome to version 8 of PostgreSQL ... The default
> encoding for initdb is ..... Ta-daaaa!!! Unicode !!!
> 
> Carlos

Various people have various perceptions. I don't feel that my suggestion
only serves to make PostgreSQL become a software product fitting only
*myself*. On the contrary, I believe PostgreSQL will become suitable for
more novice users if initdb will use UNICODE as the default characterset
when it is not given option "-E" and when it can not correctly derive a
characterset from locale.

As I stated, not all webmasters or DBA's are advanced software
administrators. I wonder there are many many webmasters and DBA's in the
world try to setup their web sites and only use a mouse but never use
their keyboards and read manuals. And I wonder this is one of the
reasons making MyZql so popular - so much popular than PostgreSQL
although it is far less powerful and has much less features than the
latter. I have been using PostgreSQL since 6.5.x. I chose it because I
noticed that PostgresSQL was the only open source DBMS that supports
subquery and user defined functions that time. But how come MyZql
becomes more popular than PostgreSQL today? I have my own answers to
this:

1. "MyZql" is easier to pronounce and remember than "PostgreSQL".
2. MyZql rolled out MyZql.exe earlier than PostgreSQL.

Answer 1 is a very important reason but I don't intend to talk about it
here. I believe MyZql's success in terms of market share is largely
contributed by its Windowz product. Why? Becasue many (and perhaps most)
people started their businesses by using a mouse. They are obviously not
advanced DBA nor experts at the begining. However, they felt they
successfully got their jobs done only with a mouse!

I feel PostgreSQL can also consider this marketing strategy:

As it has always been providing andvanced features for andvanced users,
but also first help novices, who knows only how to use a mouse, get
their jobs done.

Yes, UNICODE results in poorer performance than SQL_ASCII. However, this
is not a problem at all because advanced users will use "-E" when they
only needs SQL_ASCII. On the contrary, novices who actually needs
UNICODE but get SQL_ASCII after PostgreSQL installation usually walk
away and embrace MyZql which appears to be able to always help them
setup their first web site with a few mouse clicks and with all the
default values prompted by MyZql-install.exe.

As in my unhappy experience, the webmaster must have used initdb without
"-E" option to initialized his database cluster. He also used a cPanel
which does not provide "-E" option for createdb. I posted a request to
that site asking for providing "-E" option for createdb by his cPanel.
That webmaster said that he can not program cPanel. Another user replied
me by asking: "What don't you simply use MyZql?".  The net result is
that I left his site and reduced the total number of PostgreSQL users
from his site.

Regards,

CN

-- 
http://www.fastmail.fm - The way an email service should be


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux