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

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

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

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?

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

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)

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.

How about this for a wording:

"Schemas allow users or applications to have their own namespaces in
which to create objects.

A typical application of this is to allow creation of tables that
_appear_ to have the same name. For instance, if some GNOME
applications were using PostgreSQL to store their configuration, a
"GNUMERIC" namespace might have a table PREFERENCES to store
preferences for that application, while a "POWERSHELL" namespace
would allow _that_ application to store configuration in a
PREFERENCES table that is quite distinct from the "GNUMERIC" one.

The "true" table names may be GNUMERIC.PREFERENCES and
POWERSHELL.PREFERENCES, but by using Schemas, applications do not
need to be speckled with gratuitious added prefixes of GNUMERIC or
POWERSHELL."

Note that I'm pointing at "applications" as the primary purpose for
this, as opposed to "users."

In the long run, are not applications more likely to be the driving
force encouraging the use of schemas?
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/unix.html
"The most precisely-explained and voluminously-documented user
interface "rule" can and will be shot to pieces with the introduction
of a single new priority consideration." -- Michael Peck

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

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

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

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 restricted by removing
permissions on the public schema.

---------------------------------------------------------------------------

cbbrowne@cbbrowne.com 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.

How about this for a wording:

"Schemas allow users or applications to have their own namespaces in
which to create objects.

A typical application of this is to allow creation of tables that
_appear_ to have the same name. For instance, if some GNOME
applications were using PostgreSQL to store their configuration, a
"GNUMERIC" namespace might have a table PREFERENCES to store
preferences for that application, while a "POWERSHELL" namespace
would allow _that_ application to store configuration in a
PREFERENCES table that is quite distinct from the "GNUMERIC" one.

The "true" table names may be GNUMERIC.PREFERENCES and
POWERSHELL.PREFERENCES, but by using Schemas, applications do not
need to be speckled with gratuitious added prefixes of GNUMERIC or
POWERSHELL."

Note that I'm pointing at "applications" as the primary purpose for
this, as opposed to "users."

In the long run, are not applications more likely to be the driving
force encouraging the use of schemas?
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/unix.html
"The most precisely-explained and voluminously-documented user
interface "rule" can and will be shot to pieces with the introduction
of a single new priority consideration." -- Michael Peck

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  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

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

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

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

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

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

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

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

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

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