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.
--
20 matches
Mail list logo
