New man pages

I've posted a tarball of new man pages at

ftp://postgresql.org/pub/doc/man.tar.gz

I *think* these are ready for prime time, or close to it. They are
generated completely automatically from the sgml sources, using some
patched perl utilities. I'll try to post the complete set of docs
tools on the ftp site sometime soon.

Note that there are a few more man pages than were available in the
original versions, and that *all* information in the original man
pages appears in the new ones (or somewhere in the other docs).

I haven't yet updated the cvs tree to contain these new man pages.
Please look through the tarball and report any problems you see, if
you have any interest in the man page issue. Also, please report if
they look OK, so I know *someone* looked at them ;)

I looked at the new pages, and they looked very good, much better than I
thought they would. The only problem was the display of the command
syntax was wrapped rather than being one operator per line:

select [distinct [on attr_name]]
expression1 [as attr_name-1]
{, expression-1 [as attr_name-i]}
[into [temp] [table] classname]
[from from-list]
[where where-clause]
[group by attr_name1 {, attr_name-i....}]
[having having-clause]

became:

select [distinct [on attr_name]] expression1 [as attr_name-1]
{, expression-1 [as attr_name-i]} [into [temp] [table] classname]
[from from-list] [where where-clause] [group by attr_name1
{, attr_name-i....}] [having having-clause]

Which is almost unreadable.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

I looked at the new pages, and they looked very good, much better than I
thought they would.

:)

The only problem was the display of the command
syntax was wrapped rather than being one operator per line:
Which is almost unreadable.

Fixed it.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

I looked at the new pages, and they looked very good, much better than I
thought they would.

:)

Yes, I was prepared to really lose some of the nice formatting we had,
but we really didn't lose anything.

The only problem was the display of the command
syntax was wrapped rather than being one operator per line:
Which is almost unreadable.

Fixed it.

Thanks.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

I mentioned this earlier in the context of pg_dump, which fails
trying to create the table "pgdump_oid".

After a bit, a memory jog reminded me that I've seen this
before, with the table "foo", which I once used for testing.

After a fair number of "create/drop" cycles, making then
dropping tables for testing, pgsql now refuses to let me
"create table foo...", giving the same simple error message
"can't create foo" as pg_dump's getting on pgdump_oid.

I can't "drop table foo", getting an error message telling
me the class doesn't exist, so that's not the problem.

I CAN create/drop other tables, i.e. "create table bar..."
followed by "drop table bar" works fine.

So it doesn't appear to be a general permissions problem,
i.e. it's not as though the system thinks I don't have
create table rights.

It would seem as some system table is being corrupted???

Does this sound at all familiar?

Unfortunately, I don't know how to reproduce this other
than create/drop tables until eventually it fails. As
I mentioned in my first note, pg_dump has been running
nightly on this database for weeks, at least, with no
errors reported. Suddenly - poof! can't create pgdump_oid.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Don Baccus wrote:

I can't "drop table foo", getting an error message telling
me the class doesn't exist, so that's not the problem.

It would seem as some system table is being corrupted???

Check pg_tables and pg_class -- select * from pg_tables; will give you a
list of tables from the system catalog, and select * from ps_class; will
do the same for classes -- if the psuedo-dropped table shows in either
of these tables, delete it, and see if that helps. If this indeed is a
system table corruption..... eeewwww....

Lamar Owen
WGCR Internet Radio

At 02:14 PM 8/6/99 -0400, Lamar Owen wrote:

Don Baccus wrote:

I can't "drop table foo", getting an error message telling
me the class doesn't exist, so that's not the problem.

It would seem as some system table is being corrupted???

Check pg_tables and pg_class -- select * from pg_tables; will give you a
list of tables from the system catalog, and select * from ps_class; will
do the same for classes -- if the psuedo-dropped table shows in either
of these tables, delete it, and see if that helps. If this indeed is a
system table corruption..... eeewwww....

Neither "pgdump_oid" or "foo" (my other example from my
follow-up message) appear to exist in pg_class or pg_tables.

Thanks for the suggestion, though :(

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

At 11:23 AM 8/6/99 -0700, Don Baccus wrote:

Neither "pgdump_oid" or "foo" (my other example from my
follow-up message) appear to exist in pg_class or pg_tables.

Thanks for the suggestion, though :(

Things are getting more and more odd...

I've done some more testing and things are now in a state
where I can create a table, drop the table (and get the
message "DROP" back), yet the relation still exists.

In fact, I can do a "select count(*) from ..." on it and
get zero rows back.

Argh!

Of course, now if I try to create a table with that name,
I'm told the relation already exists.

Different than the situation with pgdump_oid and foo,
where I'm just told that the create failed.

Obviously, some table contents somewhere must be messed
up. Any ideas?

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

On Fri, Aug 06, 1999 at 11:54:31AM -0700, Don Baccus wrote:

At 11:23 AM 8/6/99 -0700, Don Baccus wrote:

Neither "pgdump_oid" or "foo" (my other example from my
follow-up message) appear to exist in pg_class or pg_tables.

Thanks for the suggestion, though :(

Things are getting more and more odd...

I've done some more testing and things are now in a state
where I can create a table, drop the table (and get the
message "DROP" back), yet the relation still exists.

In fact, I can do a "select count(*) from ..." on it and
get zero rows back.

Argh!

Of course, now if I try to create a table with that name,
I'm told the relation already exists.

Different than the situation with pgdump_oid and foo,
where I'm just told that the create failed.

Obviously, some table contents somewhere must be messed
up. Any ideas?

Check to see if there are files in the pgsql/data/base/'yourdbname'
directory called 'pgdump_oid' and 'foo'. Some situations lead to a table
being almost completely deleted, but leaving the file behind. Doesn't
explain the 'table still there' phenomena, but might let you recreate a
'dropped' table.

Ross
P.S. once common problem is dropping a table doesn't always get all the
objects created by 'convenience' types. For example, not not sure the
sequence created for a serial type gets dropped with its table. In fact,
I'm pretty sure it doesn't (and, for now, shouldn't)

--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

Don Baccus wrote:

Obviously, some table contents somewhere must be messed
up. Any ideas?

Ooooo....

If this were happening to me, I'd probably stop postmaster, rename the
PGDATA tree to something else, initdb, start postmaster, restore from
the last good dump, stop postmaster, copy back the user database dirs
under PGDATA, restart postmaster, VACUUM all tables -- on the production
machine, if that is where the problems are. Then, I'd pull that PGDATA
binary backup over to a development workstation, start up a postmaster
pointing to it, and do a post-mortem, checking all system tables for
their contents, running vacuum, et al (all the while keeping a good copy
of the old PGDATA tree -- just in case something blows up).

Obviously, some system catalog somewhere is getting farkled -- Don, I'm
assuming that you are vacuuming often.

HTHaL

Lamar

At 02:46 PM 8/6/99 -0500, Ross J. Reedstrom wrote:

Check to see if there are files in the pgsql/data/base/'yourdbname'
directory called 'pgdump_oid' and 'foo'. Some situations lead to a table
being almost completely deleted, but leaving the file behind. Doesn't
explain the 'table still there' phenomena, but might let you recreate a
'dropped' table.

Thanks, I thought of this one myself, and deleted "foo". This is
when it got into the mode of allowing "create table foo..." and
an apparently successful "drop table foo", but with "foo" left
behind in pg_class (I think that's right) and "select count(*)
from foo" returning 0 rows (i.e. the relation really seems to
exist!)

Ross
P.S. once common problem is dropping a table doesn't always get all the
objects created by 'convenience' types. For example, not not sure the
sequence created for a serial type gets dropped with its table. In fact,
I'm pretty sure it doesn't (and, for now, shouldn't)

Yes, this isn't my problem, though.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

At 03:53 PM 8/6/99 -0400, Lamar Owen wrote:

Don Baccus wrote:

Obviously, some table contents somewhere must be messed
up. Any ideas?

Ooooo....

If this were happening to me, I'd probably stop postmaster, rename the
PGDATA tree to something else, initdb, start postmaster, restore from
the last good dump, stop postmaster, copy back the user database dirs
under PGDATA, restart postmaster, VACUUM all tables -- on the production
machine, if that is where the problems are. Then, I'd pull that PGDATA
binary backup over to a development workstation, start up a postmaster
pointing to it, and do a post-mortem, checking all system tables for
their contents, running vacuum, et al (all the while keeping a good copy
of the old PGDATA tree -- just in case something blows up).

I decided awhile back to punt and rebuild.

Obviously, some system catalog somewhere is getting farkled -- Don, I'm
assuming that you are vacuuming often.

Nightly, after dumping.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Hi Thomas,

I'm looking at man pages, and I find it very good. Now we have only one
documentation's version. Nice job.
There's only a little thing that I would like to recall your attention;
I see whenever the name Postgres instead of
PostgreSQL. Is there a reason to continue to call it Postgres in the
docs ?

-------------------------------------------------------------------------

UPDATE(l) UPDATE(l)

NAME
UPDATE - Replaces values of columns in a table

SYNOPSIS
UPDATE table SET R">colle> = expression [, ...] [ FROM
^^^^^^^
fromlist ] [ WHERE condition ]

INPUTS
table The name of an existing table.

column The name of a column in table.

expression
A valid expression or value to assign to column.

fromlist
A Postgres non-standard extension to allow columns
^^^^^^^
from other tables to appear in the WHERE condition.

Jos�

Thomas Lockhart ha scritto:

There's only a little thing that I would like to recall your attention;
I see whenever the name Postgres instead of
PostgreSQL. Is there a reason to continue to call it Postgres in the
docs ?

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all
titles and introductory material. I have considered the "SQL" part of
the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
"Windows 2000", and a bit cumbersome in the body of the docs.

But that was a choice which can always be reconsidered, we're just a
"sed" away from a different name...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

There's only a little thing that I would like to recall your attention;
I see whenever the name Postgres instead of
PostgreSQL. Is there a reason to continue to call it Postgres in the
docs ?

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all
titles and introductory material. I have considered the "SQL" part of
the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
"Windows 2000", and a bit cumbersome in the body of the docs.

But that was a choice which can always be reconsidered, we're just a
"sed" away from a different name...

I vote for PostgreSQL.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Mon, 9 Aug 1999, Bruce Momjian wrote:

There's only a little thing that I would like to recall your attention;
I see whenever the name Postgres instead of
PostgreSQL. Is there a reason to continue to call it Postgres in the
docs ?

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all
titles and introductory material. I have considered the "SQL" part of
the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
"Windows 2000", and a bit cumbersome in the body of the docs.

But that was a choice which can always be reconsidered, we're just a
"sed" away from a different name...

I vote for PostgreSQL.

I'm just an end user who loves the product...with an opinion. ;-)

Although I never used postgres (i.e., prior to the suffix being appended)
I always use `postgres' in conversation both as it is easily pronounced
and as there is a rather noteable history/lineage. When communicating
with other postgres fans I say pee-gee...

When I refer specfically to the newer incarnation I say Postgres SQL
(post-gress see-qwell) rather than postgreS-Q-L...

I don't really mind if the man pages get edited as if I ever choose to
read them to my 4 year old son I will swap in the generic name, on the
fly. But we are not up to that point yet - my son is still learning
about grep. ;-)

I fully appreciate what the name is designed to convey but it does not
roll off the tongue...so I kinda like Thomas' decision to stick with
the more generic term - and the more poetic.

Cheers,
Tom

------- North Richmond Community Mental Health Center -------

Thomas Good MIS Coordinator
Vital Signs: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

/* Member: Computer Professionals For Social Responsibility */

Thomas Lockhart wrote:

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

Lamar Owen
WGCR Internet Radio

On Mon, 9 Aug 1999, Lamar Owen wrote:

Thomas Lockhart wrote:

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

I have! I don't see that there is really any difference between saying
"postgresequel" and "postgres-cue-ell". The syllables are just switched.
(kind of) However, perhaps the inventors of this term could offer their
insight into their intended pronounciation.

--
Peter Eisentraut
PathWay Computing, Inc.

Peter Eisentraut wrote:

On Mon, 9 Aug 1999, Lamar Owen wrote:

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

I have! I don't see that there is really any difference between saying
"postgresequel" and "postgres-cue-ell". The syllables are just switched.
(kind of) However, perhaps the inventors of this term could offer their
insight into their intended pronounciation.

Not post-gre'-se-quel -- post-gres'-quel. One less syllable. At least,
that's how I've been saying it. But, then again, when referring to
MySQL I don't say my-s-q-l; I say my'-squel.

Oh well...

Lamar

The only thing I hate about PostgreSQL is that it's hard to type with all
that mixed case. I confess that I've always pronounced it "postgres"
anyway, so there!

The point of a name is to be distinctive and somewhat descriptive.
Postgres suffices to set the product off from other database systems.
There's no real need for the SQL to be in the name. Even Microsoft, in
their eternal marketing battle, doesn't make a point of writing AccesSQL.

My two bits, and your mileage may vary.

On Mon, 9 Aug 1999, Peter Eisentraut wrote:

On Mon, Aug 09, 1999 at 02:51:02PM -0500, J. Michael Roberts wrote:

The only thing I hate about PostgreSQL is that it's hard to type with all
that mixed case. I confess that I've always pronounced it "postgres"
anyway, so there!

The point of a name is to be distinctive and somewhat descriptive.
Postgres suffices to set the product off from other database systems.
There's no real need for the SQL to be in the name. Even Microsoft, in
their eternal marketing battle, doesn't make a point of writing AccesSQL.

Well, that might be because MS-Access... isn't! Their SQL server product,
however is called,...

SQL Server!

Anyone else get cheesed off how MS seems to always try to co-opt generic
words and turn them into ProductNames(tm)? Word? Access? SQL? In my own
little rebellion, I make a point of prefixing MS- whenever I speak or
write about their products.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

I'll bet that even the coiners of the term have some differences in
their pronunciation. For the record, I use "Postgres" usually, and
"Postgres-cue-ell" when forced...

- Thomas

Since we cap the "S", however you pronounce "SQL" should probably be
how you do the end of "PostgreSQL". Lamar, are you a "ess-quel"
person? That may be a regional dialect. Don't even get me started on
that: it took me years to get over my strong inclination to use
"hacker" to refer to a bad, clueless programmer...

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart wrote:

I'll bet that even the coiners of the term have some differences in
their pronunciation. For the record, I use "Postgres" usually, and
"Postgres-cue-ell" when forced...

Since we cap the "S", however you pronounce "SQL" should probably be
how you do the end of "PostgreSQL". Lamar, are you a "ess-quel"
person? That may be a regional dialect.

Only in postgressive context (ouch...)

I have been known to say 'squel' (as opposed to ess-quel....). If I
could just inflect my Southern Drawl in text.... And I have said ess cue
ell (not very often...)... Oh well. Minor points. I think it goes back
to my Z80 days, where I'd pronounce the machine code -- it sounds real
strange to say "sidbateotwo" to mean CD B8 02 (CALL x'02B8' in Z80
assembler), but I have actually done that. Just a little game that a
friend and I would play.

Incidentally, radically changing the subject, I have done some tests on
the RPM-packaged perl client, with great success. I am also
experimenting with my new (3lo) RPM's, which are the first try to
package the regression tests. Now to see if they run ;-/ As soon as
the RedHat 5.2 machine (a creaky 486-100 w/16MB) finishes a good build,
I'll post. Although, I am hitting snags -- the regression tests have
some strange requirements -- ie, the resulting regress.so in the package
is built to require /usr/local/bin/perl, and /usr/local/bin/python.....
Oh well; I'll slog through it.

Now to learn enough python to be dangerous...

Lamar

I have done some tests on
the RPM-packaged perl client, with great success.

That's building the client into the distro-specific directories for
perl? Great...

I am also
experimenting with my new (3lo) RPM's, which are the first try to
package the regression tests. Now to see if they run ;-/ As soon as
the RedHat 5.2 machine (a creaky 486-100 w/16MB) finishes a good build,
I'll post. Although, I am hitting snags -- the regression tests have
some strange requirements -- ie, the resulting regress.so in the package
is built to require /usr/local/bin/perl, and /usr/local/bin/python.....
Oh well; I'll slog through it.

Keep on patching. It's pretty convenient for stuff like this...

Now to learn enough python to be dangerous...

Dangerous doesn't take very long. I haven't progressed past that yet,
at least for python (others may suggest other topics too ;)

I was just rebuilding the plain RPMs to include the .a forms of the
libraries, and noticed problems with:

1) naming the programming language shared libraries (not libpltcl.so
but pltcl.so, etc)

2) finding bin/pgaccess/README.pga (it is obsolete)
2a) bin/pgaccess/README should be included in the pgaccess docs target

Here is the spec file for you to compare to previous versions; perhaps
you can forward your spec file so I don't have to download an entire
-src.rpm to start scoping it out?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart wrote:

That's building the client into the distro-specific directories for
perl? Great...

Actually, no -- it's doing exactly what your first run of it did -- and
it works. a simple connect-slect-fetchrows sequence did exactly as
expected -- and fancier constructs worked. My take on that is to say
that, if it works, use it -- it is being put ina reasonable place with
your install, and perl is happy. I've done some fairly extensive tests
of that interface, and have yet to crash it.

some strange requirements -- ie, the resulting regress.so in the package
is built to require /usr/local/bin/perl, and /usr/local/bin/python.....
Oh well; I'll slog through it.

Keep on patching. It's pretty convenient for stuff like this...

Well, I found that it wasn't the regression tests _per se_ that was
causing a failed requires for /usr/local/bin/[perl,python], but some
miscellaneous testing scripts in the test tree -- for reasons of
completness, I'm packaging the whole test tree -- not just the
regression tests, but the performance tests, benchmarks, et al. On a
RedHat system, perl is always at /usr/bin/perl, and python is always at
/usr/bin/python, but it's easy enough to issue a which perl or which
python to make sure, and to make the RPM as portable as RPM's can get.

I was just rebuilding the plain RPMs to include the .a forms of the
libraries, and noticed problems with:

1) naming the programming language shared libraries (not libpltcl.so
but pltcl.so, etc)

Got those.

2) finding bin/pgaccess/README.pga (it is obsolete)
2a) bin/pgaccess/README should be included in the pgaccess docs target

That's one I haven't yet corrected... Although I have included 0.97b of
the pgaccess tcl script, as /usr/bin/pgaccess97, for testing.

Here is the spec file for you to compare to previous versions; perhaps
you can forward your spec file so I don't have to download an entire
-src.rpm to start scoping it out?

http://www.ramifordistat.net/postgres/postgresql-6.5.1-2lo.spec is the
one I last released. 3lo is not ready for prime-time -- however, I've
uploaded it to postgresql-6.5.1-3lo.spec.beta in the same directory,
rather than take up list bandwidth.

Lamar

On Tue, 10 Aug 1999, Thomas Lockhart wrote:

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

I'll bet that even the coiners of the term have some differences in
their pronunciation. For the record, I use "Postgres" usually, and
"Postgres-cue-ell" when forced...

- Thomas

Since we cap the "S", however you pronounce "SQL" should probably be
how you do the end of "PostgreSQL". Lamar, are you a "ess-quel"
person? That may be a regional dialect. Don't even get me started on
that: it took me years to get over my strong inclination to use
"hacker" to refer to a bad, clueless programmer...

And how do you say Linux, Thomas? I have a friend in Regina, Saskatchewan
(that's ra-Jine-ah, not ra-geen-ah) who says LINE-ex...I wince every time
I hear it. In fact, sometimes, if I'm less than fully caffeinated it
doesn't even register that he's made a reference to Linn-Ucks...
(Usually I truncate it to Lin-icks or simply: Slackware ;-)

------- North Richmond Community Mental Health Center -------

Thomas Good MIS Coordinator
Vital Signs: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

/* Member: Computer Professionals For Social Responsibility */

And how do you say Linux, Thomas? I have a friend in Regina, Saskatchewan
(that's ra-Jine-ah, not ra-geen-ah) who says LINE-ex...I wince every time
I hear it. In fact, sometimes, if I'm less than fully caffeinated it
doesn't even register that he's made a reference to Linn-Ucks...
(Usually I truncate it to Lin-icks or simply: Slackware ;-)

*rolf* Actually, that's a problem! When I first started with
linn-ucks, the person who got me going pronounced it line-ex. And
later, when I asked, she said that she intentionally mispronounced it
so she could trace the lineage of the person; that is, so she could
tell if they had learned about it from someone that she knew. Pretty
dastardly... ;)

But I try to pronounce it in Finnish rather than Texan nowadays...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

On Mon, 9 Aug 1999, Lamar Owen wrote:

Thomas Lockhart wrote:

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

Ummm, your second way is the correct pronounciation :)

Post-gres-Q-L :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Mon, 9 Aug 1999, Bruce Momjian wrote:

There's only a little thing that I would like to recall your attention;
I see whenever the name Postgres instead of
PostgreSQL. Is there a reason to continue to call it Postgres in the
docs ?

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all
titles and introductory material. I have considered the "SQL" part of
the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
"Windows 2000", and a bit cumbersome in the body of the docs.

But that was a choice which can always be reconsidered, we're just a
"sed" away from a different name...

I vote for PostgreSQL.

I second it...whenever ppl mention "postgres", i think back to our
ancestor and figure they are referring to that :(

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

The Hermit Hacker wrote:

How hard is it to say "Postgresquel", really? Don't tell me you've been
saying "Postgres cue ell".....;-)

Ummm, your second way is the correct pronounciation :)

Post-gres-Q-L :)

Correct or not, it doesn't quite flow off the tongue... Oh well. There
are more important issues than pronunciation (such as rpm -Uvh for the
rpm's...), but a little levity never exacerberated any problems....
(laughter is the best medicine!). Maybe we need you to record the
canonical pronunciation (I'll even encode to RealAudio -- and will
donate the RealServer bandwidth!), like Linus did for linux.
(lee-nooks...).

Cheers....

Lamar Owen
WGCR Internet Radio