Getting the response for Nadia Cameron together

Hi everyone,

We're due for giving Nadia Cameron a response to her queries Real Soon
Now, so am going to go through it and finalise it, etc.

So far we have this:

---

- What is the 92 scheme specification, and why has support for it been
included in the latest version of !PostgreSQL?

"Schemas" are a part of the ANSI SQL 92 (and SQL 99) specification that
allow a database to be partitioned into separate "user spaces".  This is
very important for databases which will be shared by several developers
or several departments within a company.  With schemas, it is now easy
to institute inter-user security over broad areas of the database, as
well as allowing multiple users to create database objects, such as
views and tables, without worrying about name conflicts with other users.

**or**

SQL92 is one of a series of ANSI standards for the SQL language.  SQL92
is the second of these (the first was SQL87).  PostgreSQL now supports
nearly all of this standard, and also includes some elements from the
most recently-agreed standard, SQL3 (also known as SQL99).  PostgreSQL's
support for these standards is much better than most of its competitors,
even including the large commercial databases.

---

- In the release, Neil Conway comments that the new version contains a
dependency tracking systems "that allows PostgreSQL to 'safely' support
many more subtle enhancements like the ability to drop columns". I'm
unclear on the use of "safely" here - would you be able to elaborate on
this comment further?

In previous versions of PostgreSQL, complex chains of relationships
between database objects -- things like "views w and x depend on tables
a and b which depend on table c, custom type g and function m" -- could
cause issues with backup and restore while the database was in
development, and prevented us entirely from instituting certain
commands, such as DROP COLUMN, because of the danger of breaking
dependancies.   In 7.3, we have completed the first half of a dependancy
tracking system that prevents broken dependancies and improves database
restore from backup, as well as allowing access to those commands.  For
comparison, consider that MySQL would not allow _any_ kind of dependant
objects, including Foriegn Key relationships until very recent versions,
and that MS SQL Server has been known to have the same kind of backup
and restore issues with dependant objects as PostgreSQL.   It's an
ongoing technical challenge, but one we expect to have entirely solved
by version 7.4.

**or**

"PostgreSQL 7.3 allows the owner of a table to drop a column.  If that
column is used by something else - a view or a  foreign key reference,
for example - that could cause problems elsewhere.  PostgreSQL keeps
track of dependencies so that
it will refuse to drop a column that is used by some other object.
Dropping columns is also transaction-safe, which means that it can be
done as part of a series of operations that cann all be committed or
rolled back as one.  Very few, if any, other databases support this.

---

- What are the conditions of using !PostgreSQL?

There are no license fees of any kind for PostgreSQL. You are free to
modify, use, or distribute it in any fashion (commercial or
non-commercial), under any license you choose. The only thing you have
to do is make sure the BSD license and copyright notice are included
with any versions you do distribute.  So, it's unhindered by most
traditional software license restrictions.

---

- How long did it take to develop the latest 7.3 release?

Judging from the release of 7.2.0 until 7.3.0, about 10 months.

---

- When do you expect to release the next version of the system?

Some of the bigger items that are planned for the next release include
point in time recovery and native Windows support.  While we haven't set
a formal date, initial expectations are to release 7.4 in the second
quarter of 2003.

**or**

Some of the bigger items that are planned for the next release include
point in time recovery and native Windows support.  However, the
PostgreSQL developers have a strong commitment to releasing reliable
products and never commit themselves in advance to a release date.  A
new version is released when it is ready and has been well-tested in its
beta versions.  Any even moderately serious bugs will delay the release
so that they can be fixed.

---

Any further suggestions/thoughts before we send this to her?

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi