Thread: 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. -- 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, Pennsylvania19073
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 61cash 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.. ByeShridhar -- 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, Pennsylvania19073
> 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? 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 >
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 inwhich 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 GNOMEapplicationswere using PostgreSQL to store their configuration, a"GNUMERIC" namespace might have a table PREFERENCESto storepreferences for that application, while a "POWERSHELL" namespacewould allow _that_ application to storeconfiguration in aPREFERENCES table that is quite distinct from the "GNUMERIC" one. The "true" table names may be GNUMERIC.PREFERENCES andPOWERSHELL.PREFERENCES, but by using Schemas, applications do notneedto be speckled with gratuitious added prefixes of GNUMERIC orPOWERSHELL." 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, Pennsylvania19073
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, Pennsylvania19073
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
samename. There is also a public schema for shared tables. Table/index creation can be restricted
byremoving 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,
Pennsylvania19073
OK, wording updated to add 'applications':
Schemas allow users to create objects in their own namespace so two people or applications can have
tableswith the same name. There is also a public schema for shared tables. Table/index creation can
berestricted 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,
Pennsylvania19073
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
functionsin 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, Pennsylvania19073
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,
Pennsylvania19073
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 thesefunctions 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, Pennsylvania19073
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, Pennsylvania19073