[HACKERS] 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 [EMAIL PROTECTED] | (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
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] HISTORY updated, 7.3 branded
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 in tablecmds.c to fix the triggers. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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. 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] HISTORY updated, 7.3 branded
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. --- [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HISTORY updated, 7.3 branded
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 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 [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HISTORY updated, 7.3 branded
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 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] HISTORY updated, 7.3 branded
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 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 [EMAIL PROTECTED] | (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
Re: [HACKERS] HISTORY updated, 7.3 branded
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, 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
