Getting the response for Nadia Cameron together - Mailing list pgsql-advocacy
From | Justin Clift |
---|---|
Subject | Getting the response for Nadia Cameron together |
Date | |
Msg-id | 3DF57F61.4080801@postgresql.org Whole thread Raw |
List | pgsql-advocacy |
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
pgsql-advocacy by date: