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                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 03:24:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
HISTORY updated, 7.3 branded
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,

1) Line 74/Line 20 are same. Since they are in notes for different releases, I 
suspect one of them has to move.

2)Line 61
 cash I/O improvements (Tom)

Is that 'cash' is correct(cache?)?

Sorry, if I have missed earlier threads on this. The file I am looking at is 
last updated on Aug. 25. (anoncvs.postgresql.org).

I will update once again in an hour and check again..

Bye
 Shridhar

--
There's nothing disgusting about it [the Companion].  It's just anotherlife 
form, that's all.  You get used to those things.		-- McCoy, "Metamorphosis", 
stardate 3219.8


Wed, 04 Sep 2002 13:08:56 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: HISTORY updated, 7.3 branded

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, 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,
> 
> 1) Line 74/Line 20 are same. Since they are in notes for different releases, I 
> suspect one of them has to move.
> 
> 2)Line 61
>  cash I/O improvements (Tom)
> 
> Is that 'cash' is correct(cache?)?
> 
> Sorry, if I have missed earlier threads on this. The file I am looking at is 
> last updated on Aug. 25. (anoncvs.postgresql.org).
> 
> I will update once again in an hour and check again..
> 
> Bye
>  Shridhar
> 
> --
> There's nothing disgusting about it [the Companion].  It's just anotherlife 
> form, that's all.  You get used to those things.		-- McCoy, "Metamorphosis", 
> stardate 3219.8
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 03:43:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
> 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 encodings (Tatsuo)

To:

Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo, Kaori)

She provided lots of encodings for CONVERSION.
--
Tatsuo Ishii

Wed, 04 Sep 2002 20:40:31 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: HISTORY updated, 7.3 branded
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 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                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 



04 Sep 2002 08:17:19 -0400
Rod Taylor <rbt@zort.ca>
Re: HISTORY updated, 7.3 branded
Rod Taylor <rbt@zort.ca> 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 in tablecmds.c to fix the triggers.

			regards, tom lane

Wed, 04 Sep 2002 09:49:29 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: HISTORY updated, 7.3 branded 
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 same table with the same name."

Shouldn't it read "so two people can have tables with the same name" ?
My point is that the tables are not the same, they just have the same
name.

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
"Tiene valor aquel que admite que es un cobarde" (Fernandel)


Wed, 4 Sep 2002 10:52:32 -0400 (CLT)
Alvaro Herrera <alvherre@atentus.com>
Re: HISTORY updated, 7.3 branded
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 CONVERSION, allowing loadable encodings (Tatsuo)
> 
> To:
> 
> Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo, Kaori)
> 
> She provided lots of encodings for CONVERSION.

Done:

	Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo, Kaori)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 12:56:51 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
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 contraint, not the trigger.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 12:58:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
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 namespace
> so two people can have the same table with the same name."
> 
> Shouldn't it read "so two people can have tables with the same name" ?
> My point is that the tables are not the same, they just have the same
> name.

Good point.  Updated:

           Schemas allow users to create objects in their own namespace
           so two people can have tables with the same name.  There is 
           also a public schema for shared tables.  Table/index creation
           can be restricted by removing permissions on the public schema.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 12:59:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
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 rewording:

Table Functions

            Functions can now return sets, with multiple rows
            and multiple columns.  You specify these functions in
            the SELECT FROM clause, similar to a table or view.

2. couldn't find mention of:

Data Types and Functions
========================
Add named composite type creation - CREATE TYPE typename AS (column 
definition list)

Allow anonymous composite type specification at query runtime in the 
table alias clause - FROM tablename AS aliasname(column definition list)

Add new API to simplify creation of C language table functions

Joe


Wed, 04 Sep 2002 10:08:11 -0700
Joe Conway <mail@joeconway.com>
Re: HISTORY updated, 7.3 branded
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 comments:
> 
> 1. suggested rewording:
> 
> Table Functions
> 
>             Functions can now return sets, with multiple rows
>             and multiple columns.  You specify these functions in
>             the SELECT FROM clause, similar to a table or view.

Done.

> 2. couldn't find mention of:
> 
> Data Types and Functions
> ========================
> Add named composite type creation - CREATE TYPE typename AS (column 
> definition list)
> 
> Allow anonymous composite type specification at query runtime in the 
> table alias clause - FROM tablename AS aliasname(column definition list)
> 
> Add new API to simplify creation of C language table functions

And done:

Add named composite types using CREATE TYPE typename AS (column) (Joe)
Allow composite type definition in the table alias clause (Joe)
Add new API to simplify creation of C language table functions (Joe)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 13:24:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
Bruce Momjian <pgman@candle.pha.pa.us> 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 specify these functions in
           the SELECT FROM clause, similar to a table or view.

I don't like this description: it's always been possible for functions
to return sets, it was just hard to use the feature.  Try to explain
what we really added.  Maybe:

Functions returning sets (multiple rows) and/or tuples (multiple
columns) are now much easier to use than before.  You can call
such a function in the SELECT FROM clause, treating its output
like a table.  Such a function can be declared to return RECORD,
with the actual output column set varying from one query to the
next.  Also, plpgsql functions can now return sets.

           Both multibyte and locale are now enabled by default.

s/enabled by default/always enabled/ --- AFAIK it is impossible to
disable them, so "by default" is pretty misleading.

           By default, functions can now take up to 32 parameters, and 
           identifiers can be up to 64 bytes long.

s/64/63/

Add pg_locks table to show locks (Neil)

s/table/view/

EXPLAIN now outputs as a query (Tom)

This doesn't seem to belong under the Performance heading.

Display sort keys in EXPLAIN (Tom)

Likewise.

Restrict comments to the current database

Should probably say "comments on databases".

Increase maximum number of function parameters to 32 (Bruce)                                                                      momjian

This line seems to need editing?

Modify a few error messages for consistency (Bruce)                                                                      momjian

This too.

Cleanups in array internal handling (Tom)

Joe should get credit on that one.

			regards, tom lane

Wed, 04 Sep 2002 14:37:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: HISTORY updated, 7.3 branded 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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 specify these functions in
>            the SELECT FROM clause, similar to a table or view.
> 
> I don't like this description: it's always been possible for functions
> to return sets, it was just hard to use the feature.  Try to explain
> what we really added.  Maybe:
> 
> Functions returning sets (multiple rows) and/or tuples (multiple
> columns) are now much easier to use than before.  You can call
> such a function in the SELECT FROM clause, treating its output
> like a table.  Such a function can be declared to return RECORD,
> with the actual output column set varying from one query to the
> next.  Also, plpgsql functions can now return sets.


Well, this is a summary section.  That seems like too much detail.  I
don't remember every seeing a function returning sets before.  Can you
give an example?  I can add the word "'easily' return sets" but I don't
think it is that easy.


>            Both multibyte and locale are now enabled by default.
> 
> s/enabled by default/always enabled/ --- AFAIK it is impossible to
> disable them, so "by default" is pretty misleading.



Done.

> 
>            By default, functions can now take up to 32 parameters, and 
>            identifiers can be up to 64 bytes long.
> 
> s/64/63/

Oops, got it.

> Add pg_locks table to show locks (Neil)
> 
> s/table/view/


Yep.

> 
> EXPLAIN now outputs as a query (Tom)
> 
> This doesn't seem to belong under the Performance heading.

I had it there because EXPLAIN is a performance tool, though I wondered
about that logic too.  Move to utilities.

> 
> Display sort keys in EXPLAIN (Tom)
> 
> Likewise.

Moved.

> 
> Restrict comments to the current database
> 
> Should probably say "comments on databases".

Changed to:

Restrict comment to the current database   

> 
> Increase maximum number of function parameters to 32 (Bruce)                                                                      momjian
> 
> This line seems to need editing?

Fixed.

> 
> Modify a few error messages for consistency (Bruce)                                                                      momjian
> 
> This too.

Fixed.

> 
> Cleanups in array internal handling (Tom)
> 
> Joe should get credit on that one.

Done.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 14:45:02 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
Bruce Momjian <pgman@candle.pha.pa.us> 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 features have been there, but they were messy and awkward to use.
Recall that the TODO item was
	* -Functions returning sets do not totally work
and not "we don't have functions returning sets".

			regards, tom lane

Wed, 04 Sep 2002 14:51:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: HISTORY updated, 7.3 branded 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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 features have been there, but they were messy and awkward to use.
> Recall that the TODO item was
> 	* -Functions returning sets do not totally work
> and not "we don't have functions returning sets".

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, similar to a table or view.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 15:01:39 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded
Bruce Momjian <pgman@candle.pha.pa.us> 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, similar to a table or view.

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?

There are really two independent improvements here: one is the ability
for plpgsql functions to return sets, and the other is a group of
improvements that make it easier to use a function-returning-set,
independently of what language it's written in.

			regards, tom lane

Wed, 04 Sep 2002 15:13:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: HISTORY updated, 7.3 branded 
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 to return sets, and the other is a group of
> improvements that make it easier to use a function-returning-set,
> independently of what language it's written in.
> 

As an example, although you *could* return a composite type before, it 
was almost useless, because what you actually got returned to you was a 
pointer:

test=# create function get_foo() returns setof foo as 'select * from 
foo' language sql;
CREATE
test=# select get_foo();
   get_foo
-----------
  137867648
  137867648
  137867648
(3 rows)

In order to get the individual columns, you had to do:

test=# select f1(get_foo()), f2(get_foo()), f3(get_foo());
  f1 | f2 | f3
----+----+-----
   1 |  1 | abc
   1 |  2 | def
   2 |  1 | ghi
(3 rows)

Pretty ugly, but it did work.

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.


Joe



Wed, 04 Sep 2002 12:53:20 -0700
Joe Conway <mail@joeconway.com>
Re: HISTORY updated, 7.3 branded
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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 4 Sep 2002 16:04:27 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: HISTORY updated, 7.3 branded