pg_encoding not needed anymore

On Mon, Apr 19, 2004 at 08:41:18PM -0400, Bruce Momjian wrote:

With initdb written now in C, we don't need a pg_encoding binary
anymore.

By the way, what change the name of "initdb" to "pg_initdb". The
current name is really too common (like some others things in
pgsql/src/bin)

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

Karel Zak wrote:

On Mon, Apr 19, 2004 at 08:41:18PM -0400, Bruce Momjian wrote:

With initdb written now in C, we don't need a pg_encoding binary
anymore.

By the way, what change the name of "initdb" to "pg_initdb". The
current name is really too common (like some others things in
pgsql/src/bin)

Uh, that would be pretty major. No one has complained about it in the
past. I think createuser is much worse. :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Tue, Apr 20, 2004 at 08:59:20AM -0400, Bruce Momjian wrote:

Karel Zak wrote:

On Mon, Apr 19, 2004 at 08:41:18PM -0400, Bruce Momjian wrote:

With initdb written now in C, we don't need a pg_encoding binary
anymore.

By the way, what change the name of "initdb" to "pg_initdb". The
current name is really too common (like some others things in
pgsql/src/bin)

Uh, that would be pretty major. No one has complained about it in the
past. I think createuser is much worse. :-)

Sure. Maybe is needful wait for some other project like PostgreSQL that
will use same clever names... But maybe we will never see a problem,
because the others are less ignorant...

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

Bruce Momjian wrote:

Karel Zak wrote:

On Mon, Apr 19, 2004 at 08:41:18PM -0400, Bruce Momjian wrote:

With initdb written now in C, we don't need a pg_encoding binary
anymore.

By the way, what change the name of "initdb" to "pg_initdb". The
current name is really too common (like some others things in
pgsql/src/bin)

Uh, that would be pretty major. No one has complained about it in the
past. I think createuser is much worse. :-)

Agreed. Actually, the big problem with the name "initdb" is that the
name is misleading, and newbies often get confused by it. You are
preparing a data store for many databases, not a single database. But I
think it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't go
back and fix it. Maybe we should think about a symlink/hardlink to use a
better name.

cheers

andrew

Andrew Dunstan wrote:

past. I think createuser is much worse. :-)

Agreed. Actually, the big problem with the name "initdb" is that the
name is misleading, and newbies often get confused by it. You are
preparing a data store for many databases, not a single database. But I
think it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't go
back and fix it. Maybe we should think about a symlink/hardlink to use a
better name.

Yea, initcluster would have been better, but cluster confuses with
CLUSTER, just like database schema confuses with CREATE SCHEMA.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Tue, 20 Apr 2004, Bruce Momjian wrote:

Andrew Dunstan wrote:

past. I think createuser is much worse. :-)

Agreed. Actually, the big problem with the name "initdb" is that the
name is misleading, and newbies often get confused by it. You are
preparing a data store for many databases, not a single database. But I
think it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't go
back and fix it. Maybe we should think about a symlink/hardlink to use a
better name.

Yea, initcluster would have been better, but cluster confuses with
CLUSTER, just like database schema confuses with CREATE SCHEMA.

Maybe initpg or pg_init or something like that?

g a data store for many databases, not a single database. But I think
it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't
go back and fix it. Maybe we should think about a symlink/hardlink to
use a better name.

initcatalog?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Joshua D. Drake wrote:

g a data store for many databases, not a single database. But I
think it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't
go back and fix it. Maybe we should think about a symlink/hardlink to
use a better name.

initcatalog?

initpgstore ... we can play the name game if people are serious :-)

cheers

andrew

On Tuesday 20 April 2004 16:54, Andrew Dunstan wrote:

Joshua D. Drake wrote:

g a data store for many databases, not a single database. But I
think it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't
go back and fix it. Maybe we should think about a symlink/hardlink to
use a better name.

initcatalog?

initpgstore ... we can play the name game if people are serious :-)

ooh... we havent done this is a while.... hows about....

initpgdata?

dovetails nicely with PGDATA... at least until that gets deprecated ;-)

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL