I have updated /HISTORY for 7.3beta2. Looking at the open items list, I
think we are ready for beta2 now.
---
P O S T G R E S Q L
7 . 3 O P E NI T E M S
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
--
Bruce Momjian|
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
Some minor stuff,
I assume you are not looking at the 7.3 release notes. It does take a
while for anon to get the changes.
---
Shridhar Daithankar wrote:
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
OK, the HISTORY file is updated,
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
Please change:
Add CREATE/DROP CONVERSION, allowing loadable
Found this line without a name:
Propagate column or table renaming to foreign key constraints
Is that item complete? pg_constraint follows (as such dump / restore
will work) but the triggers themselves still break, don't they?
On Wed, 2002-09-04 at 03:24, Bruce Momjian wrote:
OK, the HISTORY
Rod Taylor [EMAIL PROTECTED] writes:
Found this line without a name:
Propagate column or table renaming to foreign key constraints
Is that item complete? pg_constraint follows (as such dump / restore
will work) but the triggers themselves still break, don't they?
Yes, no. There's hackery
Shridhar Daithankar dijo:
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
Some minor stuff,
In the schema changes description:
Schemas allow users to create objects in their own namespace
so two people can have the
Shridhar Daithankar dijo:
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
Some minor stuff,
In the schema changes description:
Schemas allow users to create objects in their own namespace
so two people
Tatsuo Ishii wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
Please change:
Add CREATE/DROP
Rod Taylor wrote:
Found this line without a name:
Propagate column or table renaming to foreign key constraints
Is that item complete? pg_constraint follows (as such dump / restore
will work) but the triggers themselves still break, don't they?
No idea. The item only talks about the
Alvaro Herrera wrote:
Shridhar Daithankar dijo:
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
Some minor stuff,
In the schema changes description:
Schemas allow users to create objects in their own
OK, wording updated to add 'applications':
Schemas allow users to create objects in their own namespace
so two people or applications can have tables with the same
name. There is also a public schema for shared tables.
Table/index creation can be
Bruce Momjian wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
A few minor comments:
1. suggested
Joe Conway wrote:
Bruce Momjian wrote:
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
I used the same HISTORY categories Peter made in 7.2. I liked them.
Please review the HISTORY file. I am sure there are improvements that
can be made.
A few minor
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Please review the HISTORY file.
PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality.
s/support/supports/
Functions can now return sets, with multiple rows
and multiple columns. You
Bruce Momjian [EMAIL PROTECTED] writes:
I don't remember every seeing a function returning sets before. Can you
give an example?
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392
Also, the preceding subsection shows SQL functions returning rows. So
these
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't remember every seeing a function returning sets before. Can you
give an example?
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392
Also, the preceding subsection shows SQL functions
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, now I remember, only SQL functions could return sets. How about
this:
PL/PgSQL and C functions can now return sets, with multiple
rows and multiple columns. You specify these functions in the
SELECT FROM clause,
Tom Lane wrote:
C functions have always been able to return sets too; you don't honestly
think that a SQL function can do something a C function can't, do you?
The original dblink is an example.
There are really two independent improvements here: one is the ability
for plpgsql functions
Joe Conway wrote:
What about this:
Functions returning multiple rows and/or multiple columns are
now much easier to use than before. You can call such a
table function in the SELECT FROM clause, treating its output
like a table. Also, plpgsql functions can now return sets.
Added.
--
I have updated the HISTORY file to be current as of today. Marc, it may
be nice to repackage beta1 with that one file changed, but my guess is
that we will have a beta2 soon enough.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
22 matches
Mail list logo