Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian writes: I just committed changes that make it RESULT_OID, but if you like INSERTED_OID better, we could change it... I think I like RESULT_OID because the standard uses RESULT. RESULT* is used for SELECT statements, but RESULT_OID is for INSERT commands. It sounds a bit like that results get oids assigned. Maybe. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: I just committed changes that make it RESULT_OID, but if you like INSERTED_OID better, we could change it... I think I like RESULT_OID because the standard uses RESULT. RESULT* is used for SELECT statements, but RESULT_OID is for INSERT commands. It sounds a bit like that results get oids assigned. Maybe. I don't have a strong feeling either way, but it occurred to me that RESULT_OID might be better since it could be used for more purposes, eg, returning a last-affected-row OID for UPDATE or DELETE. Not that we do that now, but we wouldn't have to chew up additional keywords if we wanted to start doing it. regards, tom lane
AW: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
We *do* need to support ROW_COUNT, but allowing GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c; is a lot friendlier than the standard: GET DIAGNOSTICS :a = ROW_COUNT; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; GET DIAGNOSTICS :c = OID; (not that we even support SQLCODE at this stage). Informix does: GET DIAGNOSTICS :a = ROW_COUNT, EXCEPTION 1 :b = SQLCODE; separated with comma, don't know if that is standard, but it sure looks more like the standard. Andreas
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner [EMAIL PROTECTED] writes: Unfortunately, I don't have an awful lot of free time at the moment, so I won't be able to look at this for at *least* as week. It looks like a pretty straightforward change; I'll try to get it done today. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Well, this clearly is a release-stopper because we don't want to release a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by someone. I have added it to the open items list. Done. I ended up using RESULT_OID for the keyword that wasn't specified by SQL99, after I realized that it actually *is* a keyword in the plpgsql grammar, and therefore had better not conflict with any plain identifiers that a user might want to use. Both RESULT and OID look mighty dangerous from that perspective. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Well, this clearly is a release-stopper because we don't want to release a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by someone. I have added it to the open items list. Done. I ended up using RESULT_OID for the keyword that wasn't specified by SQL99, after I realized that it actually *is* a keyword in the plpgsql grammar, and therefore had better not conflict with any plain identifiers that a user might want to use. Both RESULT and OID look mighty dangerous from that perspective. Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) visibility of joined columns in JOIN clauses Stuck btree spinlocks Documentation Changes - ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner wrote: P.S. Is Jan around? He's been very quiet recently... He is, just a little quiet. I can live with it either way. The main problem, as said, is that we need to allow some keywords as identifiers in PL/pgSQL like in the main parser. Actually we added RESULT as a reserved word, what's a likely variable name inside of functions. So I think we have something to do anyway. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Sadly, we made it up. Ah so. Well, friendliness aside, I'd go with the spec's syntax. We *do* need to support ROW_COUNT, but allowing GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c; is a lot friendlier than the standard: GET DIAGNOSTICS :a = ROW_COUNT; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; GET DIAGNOSTICS :c = OID; It looks to me like SQL99 allows GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...; I like this one - except for the OID which should IMHO read INSERTED_OID. P.S. Is Jan around? He's been very quiet recently... He's still engaged in moving from Germany to Norfolk, VA. I think his net-access is somewhat erratic :-( Actually it's more the "custody for my children" thing than the movement itself. For the net-access: my mother's appartment has a phone line, so I can use my 33K6 modem for dialup - that's all. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; May I suggest that this is the wrong syntax? It should be GET DIAGNOSTICS variable = ROW_COUNT; See SQL99 part 2, clause 19.1. Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Anyone have an Oracle manual to check? Got it as a patch from - um - forgotten. Didn't new that there is something in the SQL99. I'd be more inclined to follow the spec than Oracle, anyway. But if we're going to change it, we'd better do so before 7.1 release, else we'll have a backwards-compatibility problem. Agreed. We'd need to come up with a name for the inserted-OID result, since that's not one of the spec-listed items. I'd suggest just GET DIAGNOSTICS variable = OID; which seems unlikely to conflict with any future spec extension. But maybe someone has a better idea. The problem here is that the PL/pgSQL parser doesn't have the mechanisms for enabling keywords as identifiers, the main parser has. So using an existing type name might cause some trouble. What about INSERTED_OID? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? I think both of those are actually done. Vadim might want to tweak the timeouts I selected for buffer spinlocks, but that's easily done if he does. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner wrote: Unfortunately, I don't have an awful lot of free time at the moment, so I won't be able to look at this for at *least* as week. I'll do it as soon as we decided about the final syntax and keywords. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? I think both of those are actually done. Vadim might want to tweak the timeouts I selected for buffer spinlocks, but that's easily done if he does. OK, I have removed these items. Doesn't look like much left. Let me move Lazy Vacuum to TODO, and remove ODBC. I will keep the web page in case we need to add some later. Thanks folks for clearing these items. --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) Documentation Changes - ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Bruce Momjian [EMAIL PROTECTED] writes: Open list updated. Looks like the list is done. Can I move "Stuck btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN clauses" done? I think both of those are actually done. Vadim might want to tweak the timeouts I selected for buffer spinlocks, but that's easily done if he does. Great, so you already have it using spinlocks, but using timeouts, and it will not die under heavy load. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Jan Wieck [EMAIL PROTECTED] writes: I like this one - except for the OID which should IMHO read INSERTED_OID. I just committed changes that make it RESULT_OID, but if you like INSERTED_OID better, we could change it... I think I like RESULT_OID because the standard uses RESULT. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: I like this one - except for the OID which should IMHO read INSERTED_OID. I just committed changes that make it RESULT_OID, but if you like INSERTED_OID better, we could change it... Oh boy, at your current speed, my limited internet access seems really to become kinda problem. Before I participate in the discussion you already committed. That aint fair :-) RESULT_OID is OK, or make it ONE_OF_THE_NEW_CREATED_OIDS, because in the case of an INSERT ... SELECT it isn't the entire story either way. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Peter Eisentraut [EMAIL PROTECTED] writes: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; May I suggest that this is the wrong syntax? It should be GET DIAGNOSTICS variable = ROW_COUNT; See SQL99 part 2, clause 19.1. Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Anyone have an Oracle manual to check? I'd be more inclined to follow the spec than Oracle, anyway. But if we're going to change it, we'd better do so before 7.1 release, else we'll have a backwards-compatibility problem. We'd need to come up with a name for the inserted-OID result, since that's not one of the spec-listed items. I'd suggest just GET DIAGNOSTICS variable = OID; which seems unlikely to conflict with any future spec extension. But maybe someone has a better idea. regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
Philip Warner [EMAIL PROTECTED] writes: Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Sadly, we made it up. Ah so. Well, friendliness aside, I'd go with the spec's syntax. We *do* need to support ROW_COUNT, but allowing GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c; is a lot friendlier than the standard: GET DIAGNOSTICS :a = ROW_COUNT; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; GET DIAGNOSTICS :c = OID; It looks to me like SQL99 allows GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...; which is at least as good as the SELECT syntax, if not better since each target variable and info spec are kept together. P.S. Is Jan around? He's been very quiet recently... He's still engaged in moving from Germany to Norfolk, VA. I think his net-access is somewhat erratic :-( regards, tom lane
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
At 20:40 18/02/01 -0500, Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: Hmm, that's definitely what SQL99 uses for the syntax. I wonder where Jan got the SELECT INTO syntax --- did he borrow it from Oracle? Sadly, we made it up. Ah so. Well, friendliness aside, I'd go with the spec's syntax. Probably a reasonably defensible position, too. We *do* need to support ROW_COUNT, but allowing GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c; is a lot friendlier than the standard: GET DIAGNOSTICS :a = ROW_COUNT; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; GET DIAGNOSTICS :c = OID; It looks to me like SQL99 allows GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...; Yes, but condition information (eg. SPI RESULT or SQLCODE), needs a separate statement to row information (eg. ROW_COUNT). ie. GET DIAGNOSTICS :a = ROW_COUNT, :c = OID; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; but it's not much of a problem, really. And I agree the 'x = y' syntax is better. Unfortunately, I don't have an awful lot of free time at the moment, so I won't be able to look at this for at *least* as week. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: GET DIAGNOSTICS (was Re: [HACKERS] Open 7.1 items)
GET DIAGNOSTICS :c = OID; It looks to me like SQL99 allows GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...; Yes, but condition information (eg. SPI RESULT or SQLCODE), needs a separate statement to row information (eg. ROW_COUNT). ie. GET DIAGNOSTICS :a = ROW_COUNT, :c = OID; GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE; but it's not much of a problem, really. And I agree the 'x = y' syntax is better. Unfortunately, I don't have an awful lot of free time at the moment, so I won't be able to look at this for at *least* as week. Well, this clearly is a release-stopper because we don't want to release a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by someone. I have added it to the open items list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Can someone comment on this? Seems GET DIAGNOSTICS is wrong from Peter's reading of SQL92, and mine too. Bruce Momjian writes: Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. I found: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; Looking at plpgsql/src/gram.y, it only supports PROCESSED (rows returned/affected) and RESULT (OID). The grammar indicates that only SELECT is allowed in GET DIAGNOSTICS SELECT. Jan says it works for INSERT/UPDATE/DELETE too, but I guess you still use GET DIAGNOSTICS SELECT. May I suggest that this is the wrong syntax? It should be GET DIAGNOSTICS variable = ROW_COUNT; See SQL99 part 2, clause 19.1. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Hi there... I would like to inquire of possible support for running PostgreSQL on a Linux Cluster. How would i implement and configure PostgreSQL as a distributed database i.e. replicated on several servers? I am anxious to hear from you guys. -- Manny C. Cabido e-mail:[EMAIL PROTECTED] [EMAIL PROTECTED] =
[HACKERS] Open 7.1 items
As you can see from the current open items list, there isn't much left to do for the 7.1 release. I am going to suggest we remove the LAZY VACUUM option at this point. I know Tom Lane posted an item about the join visibility issue, so hopefully this can be resolved soon. Not sure what to do about the "Stuck spinlocks" but we may have to leave that for 7.2 or see what problem reports we get from the current code. The documentation list is pretty much done. It would be nice to have some more items completed, but I haven't see any comments about them. So, where are we in the release cycle? Are we ready to start looking at dates to issue release candidates for testing? Thomas Lockhart needs the docs frozen for a while so he can package them. --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) visibility of joined columns in JOIN clauses Stuck btree spinlocks Documentation Changes - JDBC improvements (Peter, Travis Bauer, Christopher Cain, William Webber, Gunnar) ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) Improve PL/PgSQL documentation (?) Store tables as files named by OID (Vadim) New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names New pg_class.relkind value for views (Mark Hollomon) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. Improve PL/PgSQL documentation (?) I agree with the "(?)"... Certainly a bit late to start an "improvement" project. Store tables as files named by OID (Vadim) This has never been documented to the contrary AFAIK. There's an empty "Storage" chapter, which would be a good place to put this --- eventually. New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names These both have their appropriate READMEs. New pg_class.relkind value for views (Mark Hollomon) Documented. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. I found: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; Looking at plpgsql/src/gram.y, it only supports PROCESSED (rows returned/affected) and RESULT (OID). The grammar indicates that only SELECT is allowed in GET DIAGNOSTICS SELECT. Jan says it works for INSERT/UPDATE/DELETE too, but I guess you still use GET DIAGNOSTICS SELECT. Improve PL/PgSQL documentation (?) I agree with the "(?)"... Certainly a bit late to start an "improvement" project. I heard someone was working on that and was not sure how far they were. As I remember, docs can pretty much be done anytime before doc freeze. Probably will not happen in 7.1. Item removed. Store tables as files named by OID (Vadim) This has never been documented to the contrary AFAIK. There's an empty "Storage" chapter, which would be a good place to put this --- eventually. OK, Removed. New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names These both have their appropriate READMEs. Yes, I kept rserv in there in case we wanted to more prominently mention it in the HISTORY file and give an overview. Guess not. Seems like a pretty cool thing to keep hidden in /contrib. The /rserv README doesn't adequately describe its usefulness. All removed. New pg_class.relkind value for views (Mark Hollomon) Documented. Removed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: Bruce Momjian writes: New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) If someone can show me an example of how it operates I can write up something. I found: Quoting a recent message by Jan Wieck [EMAIL PROTECTED]: :Do a : :GET DIAGNOSTICS SELECT PROCESSED INTO int4_variable; : :directly after an INSERT, UPDATE or DELETE statement and you'll know :how many rows have been hit. : :Also you can get the OID of an inserted row with : :GET DIAGNOSTICS SELECT RESULT INTO int4_variable; Looking at plpgsql/src/gram.y, it only supports PROCESSED (rows returned/affected) and RESULT (OID). The grammar indicates that only SELECT is allowed in GET DIAGNOSTICS SELECT. Jan says it works for INSERT/UPDATE/DELETE too, but I guess you still use GET DIAGNOSTICS SELECT. May I suggest that this is the wrong syntax? It should be GET DIAGNOSTICS variable = ROW_COUNT; See SQL99 part 2, clause 19.1. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Any possibility of putting my getlocale into contrib ? I agree that it should in fact be in the pg_locale.c but that would be a feature and we don't add new features this late. OTOH it is helpful if users (specially those that use rpm's or other packaged binaries) have an easy way to find out what locale they happen to run in (as it often it just happens ;) -- Hannu
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Any possibility of putting my getlocale into contrib ? I agree that it should in fact be in the pg_locale.c but that would be a feature and we don't add new features this late. OTOH it is helpful if users (specially those that use rpm's or other packaged binaries) have an easy way to find out what locale they happen to run in (as it often it just happens ;) Actually, I have something from Oliver Elphick called pg_controldata: $ pg_controldata Log file id: 0 Log file segment: 5 Last modified:Wed Feb 7 19:35:47 2001 Database block size: 8192 Blocks per segment of large relation: 131072 Catalog version number: 200101061 LC_COLLATE: en_GB LC_CTYPE: en_GB Log archive directory: This looks quite valuable. Do people want this in /contrib? How does this compare to your utility? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: Bruce Momjian wrote: P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Any possibility of putting my getlocale into contrib ? I agree that it should in fact be in the pg_locale.c but that would be a feature and we don't add new features this late. OTOH it is helpful if users (specially those that use rpm's or other packaged binaries) have an easy way to find out what locale they happen to run in (as it often it just happens ;) Actually, I have something from Oliver Elphick called pg_controldata: Could you send it to me so that I can find out how he gets the LC_COLLATE and LC_CTYPE from backend (assuming it tells backend locale not cients) ? $ pg_controldata Log file id: 0 Log file segment: 5 Last modified:Wed Feb 7 19:35:47 2001 Database block size: 8192 Blocks per segment of large relation: 131072 Catalog version number: 200101061 LC_COLLATE: en_GB LC_CTYPE: en_GB Log archive directory: This looks quite valuable. Do people want this in /contrib? How does this compare to your utility? Mine is an external C funtion, so it can easily be used from any client. And I intend to propose it into pg_locale.c ealy in 7.2 development. --- Hannu
Re: [HACKERS] Open 7.1 items
Actually, I have something from Oliver Elphick called pg_controldata:
Could you send it to me so that I can find out how he gets the
LC_COLLATE
and LC_CTYPE from backend (assuming it tells backend locale not cients)
?
$ pg_controldata
Log file id: 0
Log file segment: 5
Last modified:Wed Feb 7 19:35:47 2001
Database block size: 8192
Blocks per segment of large relation: 131072
Catalog version number: 200101061
LC_COLLATE: en_GB
LC_CTYPE: en_GB
Log archive directory:
This looks quite valuable. Do people want this in /contrib? How does
this compare to your utility?
Mine is an external C funtion, so it can easily be used from any client.
And I intend to propose it into pg_locale.c ealy in 7.2 development.
His is an external C program also. The C source is attached.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
/* pg_controldata
*
* reads the data from $PGDATA/global/pg_control
*
* copyright (c) Oliver Elphick [EMAIL PROTECTED], 2001;
* licence: BSD
*
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include time.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
typedef unsigned int uint32;
#include "config.h"
#include "access/xlogdefs.h"
/*
* #include "access/xlog.h"
* #include "c.h"
*/
/* The following definitions are extracted from access/xlog.h and its
* recursive includes. There is too much initialisation needed if
* they are included direct. Perhaps someone more knowledgeable can
* fix that.
*/
typedef struct crc64
{
uint32 crc1;
uint32 crc2;
} crc64;
#define LOCALE_NAME_BUFLEN 128
typedef enum DBState
{
DB_STARTUP = 0,
DB_SHUTDOWNED,
DB_SHUTDOWNING,
DB_IN_RECOVERY,
DB_IN_PRODUCTION
} DBState;
typedef struct ControlFileData
{
crc64crc;
uint32 logId; /* current log file id */
uint32 logSeg;/* current log file segment (1-based) */
struct
XLogRecPtr checkPoint;/* last check point record ptr */
time_t time; /* time stamp of last modification */
DBState state; /* see enum above */
/*
* this data is used to make sure that configuration of this DB is
* compatible with the backend executable
*/
uint32 blcksz;/* block size for this DB */
uint32 relseg_size; /* blocks per segment of large relation */
uint32 catalog_version_no; /* internal version number */
/* active locales --- "C" if compiled without USE_LOCALE: */
char lc_collate[LOCALE_NAME_BUFLEN];
char lc_ctype[LOCALE_NAME_BUFLEN];
/*
* important directory locations
*/
char archdir[MAXPGPATH]; /* where to move offline log files */
} ControlFileData;
int main() {
ControlFileData ControlFile;
int fd;
char ControlFilePath[MAXPGPATH];
char *DataDir;
char tmdt[32];
DataDir = getenv("PGDATA");
if ( DataDir == NULL ) {
fprintf(stderr,"PGDATA is not defined\n");
exit(1);
}
snprintf(ControlFilePath, MAXPGPATH, "%s/global/pg_control", DataDir);
if ((fd = open(ControlFilePath, O_RDONLY)) == -1) {
perror("Failed to open $PGDATA/global/pg_control for reading");
exit(2);
}
read(fd, ControlFile, sizeof(ControlFileData));
strftime(tmdt, 32, "%c", localtime((ControlFile.time)));
printf("Log file id: %u\n"
"Log file segment: %u\n"
"Last modified:%s\n"
"Database block size: %u\n"
"Blocks per segment of large relation: %u\n"
"Catalog version number: %u\n"
"LC_COLLATE: %s\n"
"LC_CTYPE: %s\n"
"Log archive directory:%s\n",
ControlFile.logId,
ControlFile.logSeg,
tmdt,
ControlFile.blcksz,
ControlFile.relseg_size,
ControlFile.catalog_version_no,
ControlFile.lc_collate,
ControlFile.lc_ctype,
ControlFile.archdir);
return (0);
}
Re: [HACKERS] Open 7.1 items
As you can see from the current open items list, there isn't much left to do for the 7.1 release. I am going to suggest we remove the LAZY VACUUM option at this point. I know Tom Lane posted an item about the Well, leaving for vacation tomorrow I have to agree -:( LAZY patch will be available in a few days after 7.1 release. Vadim
Re: [HACKERS] Open 7.1 items
[ Charset ISO-8859-1 unsupported, converting... ] As you can see from the current open items list, there isn't much left to do for the 7.1 release. I am going to suggest we remove the LAZY VACUUM option at this point. I know Tom Lane posted an item about the Well, leaving for vacation tomorrow I have to agree -:( LAZY patch will be available in a few days after 7.1 release. Seems we should keep it as an option outside the tree for a while. Remember, pgindent will be done before final. Is that OK? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Open 7.1 items
I have removed the following open item by adding the other mysql conversion utility to the CVS tree in /contrib/mysql: Merge MySQL/PgSQL translation scripts If someone wants to merge them and make one script out of them, go ahead. Both are BSD licensed now. The only remaining source code items are pretty exotic and will have to be discussed. Thanks for shrinking this list so fast. --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- LAZY VACUUM (Vadim) visibility of joined columns in JOIN clauses Stuck btree spinlocks Documentation Changes - JDBC improvements (Peter, Travis Bauer, Christopher Cain, William Webber, Gunnar) ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) New ALTER TABLE ADD CONSTRAINT (Stephan) New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) Store tables as files named by OID (Vadim) New SQL function setval(seq,val,bool) for use in pg_dump (Philip) New /contrib/rserv replication toolkit (Vadim) New /contrib/oid2name to map numeric files to table names (B Palmer) New pg_class.relkind value for views (Mark Hollomon) Moved macmanuf to /contrib (Larry Rosenman) Allow NetBSD's libedit instead of readline (Peter) Improve PL/PgSQL documenation (?) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Open 7.1 items
Attached is a list of open source code and documentation items for 7.1. If people can just confirm completed items, I will remove them right away. The current version of this file can be seen at: ftp://candle.pha.pa.us/pub/postgresql/open_items --- P O S T G R E S Q L 7 . 1 O P E NI T E M S Source Code Changes --- LAZY VACUUM (Vadim) ODBC not disconnecting properly? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux unixODBC Documentation Changes - Fix PL/perl (Alex Kapranoff) Add OUTER JOINs (Tom) Function manager overhaul (Tom) JDBC improvements (Peter, Travis Bauer, Christopher Cain, William Webber, Gunnar) Grand Unified Configuration scheme/GUC. Many options can now be set in data/postgresql.conf, postmaster/postgres flags, or SET commands (Peter E) Overhaul initdb process (Tom, Peter E) Overhaul of inherited tables; inherited tables now accessed by default; new ONLY keyword prevents it (Chris Bitmead, Tom) ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs, Michael Fork) Overhaul pg_dump (Philip Warner) New pg_dump tar output option (Philip) New pg_dump of large objects (Philip) New pg_restore command (Philip) Allow pg_hba.conf secondary password file to specify only username (Peter E) New SET SESSION CHARACTERISTICS (Thomas) Add WITHOUT TIME ZONE type qualifier (Thomas) New ALTER TABLE ADD CONSTRAINT (Stephan) New VARIANCE and STDDEV() aggregates New ESCAPE option to LIKE (Thomas) New case-insensitive LIKE - ILIKE (Thomas) Allow SQL functions to be used in more contexts (Tom) New pg_config utility (Peter E) New PL/pgSQL EXECUTE command which allows dynamic SQL and utility statements (Jan) New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) New quote_identifiers() and quote_literal() functions (Jan) New ALTER TABLE table OWNER TO user command (Mark Hollomon) Allow subselects in FROM, i.e. FROM (SELECT ...) [AS] alias (Tom) Store tables as files named by OID (Vadim) New SQL function setval(seq,val,bool) for use in pg_dump (Philip) New pg_service.conf file (Mario Weilguni) New pg_dumpall --globals-only option (Peter E) New CHECKPOINT command for WAL which creates new WAL log file (Vadim) New AT TIME ZONE syntax (Thomas) Allow location of Unix domain socket to be configurable (David J. MacKenzie) Allow postmaster to listen on a specific IP address (David J. MacKenzie) Allow socket path name to be specified in hostname by using leading slash (David J. MacKenzie) Allow CREATE DATABASE to specify template database (Tom) New pg_dump --globals-only option (Peter E) New /contrib/rserv replication toolkit (Vadim) New file format for COPY BINARY (Tom) New /contrib/oid2name to map numeric files to table names (B Palmer) Allow BIGINT as synonym for INT8 (Peter E) New BIT and BIT VARYING types (Adriaan Joubert, Tom, Peter E) Fix CIDR output formatting (Tom) New CIDR abbrev() function (Tom) Write-Ahead Log (WAL) to provide crash recovery with less performance overhead (Vadim) Store all large objects in a single table (Denis Perchine, Tom) New function manager call conventions (Tom) New configure --enable-syslog option (Peter E) configure script moved to top level, not /src (Peter E) New configure --with-python option (Peter E) New OpenSSL configuration option (Magnus, Peter E) Remove colon and semi-colon operators (Thomas) New pg_class.relkind value for views (Mark Hollomon) Rename ichar() to chr() (Karel) Moved macmanuf to /contrib (Larry Rosenman) New template0 database that contains no user additions (Tom) Allow *BSD's libedit instead of readline (Peter) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian [EMAIL PROTECTED] writes: Attached is a list of open source code and documentation items for 7.1. I've got two major TODO items that are not in your list, but should be: * visibility of joined columns in JOIN clauses (Thomas thinks code is wrong, I'm not sure yet) * separate client- and server-side includes, make optional install target to install all of src/include The question of what to do about spinlock timeouts on buffers seems to be a critical issue, too. regards, tom lane
Re: [HACKERS] Open 7.1 items
Store all large objects in a single table (Denis Perchine, Tom) Hmmm... If you would point me to the document where changes should be done, I will do them. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
Re: [HACKERS] Open 7.1 items
I have no idea. If we mention the existance of separate large object files, they it has to be updated. If we don't mention it, then we can remove the item. [ Charset ISO-8859-1 unsupported, converting... ] Store all large objects in a single table (Denis Perchine, Tom) Hmmm... If you would point me to the document where changes should be done, I will do them. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 -- -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
At 12:26 9/02/01 -0500, Bruce Momjian wrote: Overhaul pg_dump (Philip Warner) New pg_dump tar output option (Philip) New pg_dump of large objects (Philip) New pg_restore command (Philip) The SGML docs for these have been there for a while - is there something else I need to do? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Open 7.1 items
At 12:26 9/02/01 -0500, Bruce Momjian wrote: Overhaul pg_dump (Philip Warner) New pg_dump tar output option (Philip) New pg_dump of large objects (Philip) New pg_restore command (Philip) The SGML docs for these have been there for a while - is there something else I need to do? No, I just needed to know it was done. Removed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
separate client- and server-side includes, make optional install target to install all of src/include This is done now, at least as far as the source tree goes (dunno how Lamar plans to handle it in the RPMs). New file format for COPY BINARY (Tom) Already documented, see COPY reference page. New function manager call conventions (Tom) This is probably adequately documented for now: xfunc.sgml gives an overview and refers to src/backend/utils/fmgr/README for more details. At some point it'd be nice to transform that README into SGML doco, but I doubt I'll get to it before 7.1 goes out. New template0 database that contains no user additions (Tom) The CREATE DATABASE reference page discusses template0. Do we need to discuss it anywhere else? regards, tom lane
Re: [DOCS] Re: [HACKERS] Open 7.1 items
Items removed. Thanks. separate client- and server-side includes, make optional install target to install all of src/include This is done now, at least as far as the source tree goes (dunno how Lamar plans to handle it in the RPMs). New file format for COPY BINARY (Tom) Already documented, see COPY reference page. New function manager call conventions (Tom) This is probably adequately documented for now: xfunc.sgml gives an overview and refers to src/backend/utils/fmgr/README for more details. At some point it'd be nice to transform that README into SGML doco, but I doubt I'll get to it before 7.1 goes out. New template0 database that contains no user additions (Tom) The CREATE DATABASE reference page discusses template0. Do we need to discuss it anywhere else? regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Thanks, Peter. This is a big help. At 15:02 29/01/01 -0500, Bruce Momjian wrote: LAZY VACUUM (Vadim) Runtime btree recovery (Vadim) JDBC setMaxRows() is global variable affecting other objects Now fixed. When called from within a Statement it uses its maxrows value, but internal queries don't have a restriction. JDBC LargeObject short read return value missing Fixed. LargeObject.read(byte[],int,int) now returns the number of bytes actualy read. ODBC not disconnecting properly? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux unixODBC -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
At 15:02 29/01/01 -0500, Bruce Momjian wrote: LAZY VACUUM (Vadim) Runtime btree recovery (Vadim) JDBC setMaxRows() is global variable affecting other objects Now fixed. When called from within a Statement it uses its maxrows value, but internal queries don't have a restriction. JDBC LargeObject short read return value missing Fixed. LargeObject.read(byte[],int,int) now returns the number of bytes actualy read. ODBC not disconnecting properly? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux unixODBC -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Also I'm not quite sure "#arg" (stringification) is portable enough in all platforms.) The patch looks fine to me, but I have no idea how portable #arg is Use the CppAsString macro from our c.h ... that's what it's for. It's actually fairly unlikely that anyone still uses a compiler that doesn't grok #arg and yet can handle the other ANSI-isms that Postgres requires. However, we may as well stick to the coding conventions we have... Oh I see. -- Tatsuo Ishii
Re: [HACKERS] Open 7.1 items
Tatsuo Ishii [EMAIL PROTECTED] writes: Thanks. BTW, are you going to make a back patch for the 7.0.x tree? I'm sure we are going to have lots of complaints from users who are developing their own user defined functions and about to use pg_dump to upgrade to 7.1 after it is officially released... No more than in any prior release, AFAICS; these issues have been there for a long time. I doubt that a back-patch is warranted. regards, tom lane
Re: [HACKERS] Open 7.1 items
* Bruce Momjian [EMAIL PROTECTED] [010129 14:03]: Fix ipcclean on Linux I believe Peter_E handled the above last week -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Open 7.1 items
* Bruce Momjian [EMAIL PROTECTED] [010129 14:03]: Fix ipcclean on Linux I believe Peter_E handled the above last week All I see is below, and the diff -c shows just the grep change. --- revision 1.7 date: 2001/01/25 16:32:25; author: petere; state: Exp; lines: +2 -2 Avoid bogus failures due to 'ps x | grep postmaster' detecting 'grep postmaster' process. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
* Bruce Momjian [EMAIL PROTECTED] [010129 14:40]: * Bruce Momjian [EMAIL PROTECTED] [010129 14:03]: Fix ipcclean on Linux I believe Peter_E handled the above last week All I see is below, and the diff -c shows just the grep change. I thought that was all that was crabbed about?... --- revision 1.7 date: 2001/01/25 16:32:25; author: petere; state: Exp; lines: +2 -2 Avoid bogus failures due to 'ps x | grep postmaster' detecting 'grep postmaster' process. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Open 7.1 items
* Bruce Momjian [EMAIL PROTECTED] [010129 14:40]: * Bruce Momjian [EMAIL PROTECTED] [010129 14:03]: Fix ipcclean on Linux I believe Peter_E handled the above last week All I see is below, and the diff -c shows just the grep change. I thought that was all that was crabbed about?... No, there were some bad variable uses and stuff. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Here are the open items for 7.1. Much shorter: + Runtime btree recovery Vadim
Re: [HACKERS] Open 7.1 items
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches).
...
Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.)
The patch looks fine to me, but I have no idea how portable #arg is - does
anybody else have some facts on the matter:
+#define AGG_NOTICE(arg) {\
+ fprintf(stderr, "Notice: aggregate \"%s\"(oid %s) is not
dumped.\n",agginfo[i].aggname, a
+ fprintf(stderr, "Reason: " #arg);\
+ fprintf (stderr, " (oid %s) not found.\n",agginfo[i].arg);\
+ }
+
It's easy enough to change the macros to take 2 params, and that would be
my inclination if it's not a solid part of the C standard (for any
non-trivial definintion of 'solid').
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___ |
Http://www.rhyme.com.au |/ \|
|----
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Open 7.1 items
Philip Warner [EMAIL PROTECTED] writes: Also I'm not quite sure "#arg" (stringification) is portable enough in all platforms.) The patch looks fine to me, but I have no idea how portable #arg is Use the CppAsString macro from our c.h ... that's what it's for. It's actually fairly unlikely that anyone still uses a compiler that doesn't grok #arg and yet can handle the other ANSI-isms that Postgres requires. However, we may as well stick to the coding conventions we have... regards, tom lane
Re: [HACKERS] Open 7.1 items
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote: Fix for pg_dump of bad system tables Ok. I have made patches for fixing some of pg_dump problems(see attached patches). The patches address the problem with user defined functions, operators and aggregates. These have now been applied with minor modifications. However I have not address what Tom Lane said yet(actually I do not understand what he says). The other flavor of problems that pg_dump has in this area are in doing inner joins across system catalogs ... This refers to things like: SELECT c.relname FROM pg_index i, pg_class c WHERE i.indrelid = %s AND i.indisprimary AND c.oid = i.indexrelid ie. where two or more relations are crossed (pg_index and pg_class in this case). It assumes that the metadata is valid, and will not highlight missing data in the secondary table. We should be doing outer joins: SELECT c.relname FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid WHERE i.indrelid = %s AND i.indisprimary and checking for nulls using PQgetisnull. I have actually done this for a couple of SELECTs (including the above one), and marked all the others as ': use LOJ'. There are only 2 or 3 more, but they require a little more thought (an inderstanding) before I change them. In my view this should be considered a 'work-in-progress' and not hold up 7.1 since the problem has been there for a long time. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Open 7.1 items
I assume this addresses the open item: Fix for pg_dump of bad system tables I will remove it from the list. Thanks. At 07:24 26/01/01 +0900, Tatsuo Ishii wrote: Fix for pg_dump of bad system tables Ok. I have made patches for fixing some of pg_dump problems(see attached patches). The patches address the problem with user defined functions, operators and aggregates. These have now been applied with minor modifications. However I have not address what Tom Lane said yet(actually I do not understand what he says). The other flavor of problems that pg_dump has in this area are in doing inner joins across system catalogs ... This refers to things like: SELECT c.relname FROM pg_index i, pg_class c WHERE i.indrelid = %s AND i.indisprimary AND c.oid = i.indexrelid ie. where two or more relations are crossed (pg_index and pg_class in this case). It assumes that the metadata is valid, and will not highlight missing data in the secondary table. We should be doing outer joins: SELECT c.relname FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid WHERE i.indrelid = %s AND i.indisprimary and checking for nulls using PQgetisnull. I have actually done this for a couple of SELECTs (including the above one), and marked all the others as ': use LOJ'. There are only 2 or 3 more, but they require a little more thought (an inderstanding) before I change them. In my view this should be considered a 'work-in-progress' and not hold up 7.1 since the problem has been there for a long time. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
At 23:14 27/01/01 -0500, Bruce Momjian wrote: I assume this addresses the open item: Fix for pg_dump of bad system tables I will remove it from the list. Thanks. I'd remove it from the 'Required for 7.1' list, but leave it on the TODO list, since the task is not quite complete. OK, do you have some text for me. FYI, the "open" list are not all must-do items for 7.1. They are merely items that either need to be done, or moved to the TODO list. It is up to the group to decide which one they want. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
At 23:14 27/01/01 -0500, Bruce Momjian wrote: I assume this addresses the open item: Fix for pg_dump of bad system tables I will remove it from the list. Thanks. I'd remove it from the 'Required for 7.1' list, but leave it on the TODO list, since the task is not quite complete. At 07:24 26/01/01 +0900, Tatsuo Ishii wrote: Fix for pg_dump of bad system tables Ok. I have made patches for fixing some of pg_dump problems(see attached patches). The patches address the problem with user defined functions, operators and aggregates. These have now been applied with minor modifications. ... In my view this should be considered a 'work-in-progress' and not hold up 7.1 since the problem has been there for a long time. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Open 7.1 items
Hiroshi Inoue writes: What does this item mean ? Is it the following ? begin; insert into pk (id) values (1); update(delete from) pk where id=1; ERROR: triggered data change violation on relation pk" If so, isn't it a simple bug ? Depends on the definition of "bug". It's not spec compliant and it's not documented and it's annoying. But it's been like this for a year and the issue is well known and can normally be avoided. It looks like a documentation to-do to me. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: Here are my open 7.1 items. Thanks for shrinking the list so far. --- FreeBSD locale bug Reorder INSERT firing in rules I don't recall why this is wanted. AFAIK there's no reason NOT to do so, except for the actual state of beeing far too close to a release candidate. Philip Warner UPDATE crash JDBC LargeObject short read return value missing SELECT cash_out(1) crashes all backends LAZY VACUUM FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? Consider you have a deferred "ON DELETE CASCADE" constraint and do a DELETE, INSERT of a PK. Do the FK rows need to be deleted or not? Consider you have a deferred "ON DELETE RESTRICT" and "ON UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2 to PK1, the FK2 rows need to follow, but does PK2 inherit all FK1 rows now so it's the master of both groups? These are only two possible combinations. There are many to think of. As said, I've asked before, but noone voted yet. Move the item to 7.2 anyway, because changing this behaviour would require massive changes in the trigger queue *and* the generic RI triggers, which cannot be tested enough any more. Jan Usernames limited in length Does pg_dump preserve COMMENTs? Failure of nested cursors in JDBC JDBC setMaxRows() is global variable affecting other objects Does JDBC Makefile need current dir? Fix for pg_dump of bad system tables Steve Howe failure query with rules ODBC/JDBC not disconnecting properly? Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux Merge global and template BKI files? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
AW: [HACKERS] Open 7.1 items
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? Sorry, to answer late. I didn't know this needed clarification. The answer is simple, foreign keys only reference a key value, not a particular row. Andreas
RE: [HACKERS] Open 7.1 items
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? I think first. The last is closer to OODBMS world, not to [O]RDBMS one. Consider you have a deferred "ON DELETE CASCADE" constraint and do a DELETE, INSERT of a PK. Do the FK rows need to be deleted or not? Good example. I think FK should not be deleted. If someone really want to delete "old" FK then he can do DELETE PK; SET CONSTRAINT ... IMMEDIATE; -- FK need to be deleted here INSERT PK; Consider you have a deferred "ON DELETE RESTRICT" and "ON UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2 to PK1, the FK2 rows need to follow, but does PK2 inherit all FK1 rows now so it's the master of both groups? Yes. Again one can use SET CONSTRAINT to achieve desirable results. It seems that SET CONSTRAINT was designed for these purposes - ie for better flexibility. Though, it would be better to look how other DBes handle all these cases -:) Vadim
Re: [HACKERS] Open 7.1 items
Jan Wieck [EMAIL PROTECTED] writes: Bruce Momjian wrote: Reorder INSERT firing in rules I don't recall why this is wanted. AFAIK there's no reason NOT to do so, except for the actual state of beeing far too close to a release candidate. I think I've been the main person arguing for this change, but I agree with Jan that this late in the cycle is not the time to be making such decisions. Let's discuss it again during 7.2 cycle. regards, tom lane
Re: [HACKERS] Open 7.1 items
Bruce Momjian [EMAIL PROTECTED] writes: SELECT cash_out(1) crashes all backends OK, removed from 'open' list and added to TODO. Actually, I can't get the crash to happen except with cash_out. Is there another *out function you can get to fail. Any pass-by-reference type; also most if not all input functions. regards, tom lane
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. Moved to TODO. Usernames limited in length Yeah, they are. ;-) If this is referring to pg_passwd, I just had a closer look and it's really a desaster. Both password and username as well as line length and file length (in lines) have arbitrary limits, sometimes not even consistent ones. To fix this to a point where one is confident that everything works one essentially would have to rewrite the whole thing. Added to TODO: * Fix username/password length limits in all areas Does pg_dump preserve COMMENTs? Sure OK, thanks. Someone submitted a patch, and I wasn't sure how to handle it. I thought it did it already. Fix ipcclean on Linux Consider it done. Thanks. Merge global and template BKI files? Not this release. Added to TODO. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: AW: [HACKERS] Open 7.1 items
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? Sorry, to answer late. I didn't know this needed clarification. The answer is simple, foreign keys only reference a key value, not a particular row. Cite chapter and verse in the spec, please? regards, tom lane
[HACKERS] Open 7.1 items
Here are the open items for 7.1. Much shorter: Reorder INSERT firing in rules JDBC LargeObject short read return value missing LAZY VACUUM JDBC setMaxRows() is global variable affecting other objects Fix for pg_dump of bad system tables ODBC not disconnecting properly? Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux unixODBC -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Quoting Bruce Momjian [EMAIL PROTECTED]:
I have trickled the emails as I reviewed them, asking for comments. It
was not one big email.
I haven't seen them either, although my Inbox is big again, and I'm filtering
out mails by their subject line, so it's possible I've missed them.
I'm slowly working my way through JDBC, but it's all hinging on getting my
linux box back online. It's powered up, but not talking to the network :-(
Should be sorted by Saturday morning...
Peter
haven't seen it posted to hackers, or, if I did, I didn't clue into it
...
and just checked to see if maybe it was waiting for approval due to
size,
and nothing in the queue ...
posting it here is easier to respond to ...
On Wed, 24 Jan 2001, Bruce Momjian wrote:
I have about 20 open 7.1 items that I need to get resolved before I
can
start getting the doc TODO list started. The issues relate to
JDBC,
ODBC, and lots of other stuff that need to be settled before we can
finalize 7.1.
They can not be easily summarized in one line. You really have to
see
the whole email to understand the issues.
How do people want to do this? I can post them to hackers, or put
them
on my web site. I posted them to hackers during the past few days,
but
many went unanswered. These are all relatively new from the past
few
months.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania
19026
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
scrappy@{freebsd|postgresql}.org
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania
19026
--
Peter Mount [EMAIL PROTECTED]
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [HACKERS] Open 7.1 items
Bruce Momjian [EMAIL PROTECTED] writes: Here are my open 7.1 items. Thanks for shrinking the list so far. SELECT cash_out(1) crashes all backends This isn't a "must fix for 7.1", any more than it was for 7.0, 6.5, or any other release back to the beginning of time. It's always been possible to crash the backend by passing an incompatible argument to a type input or output function. The type-checking system cannot detect the error because these functions are (mostly) declared to take "any" input type (zero entry in proargtypes[]). The only clean way to fix this is to declare I/O functions honestly. That will require (a) a type-system representation for "C string" and (b) a solution to the circularity issue for user-defined types. If the I/O functions have to be declared first, how can they refer to the type? Quite aside from the time involved, this will require an initdb. It's a bit late in the cycle for that. regards, tom lane
Re: [HACKERS] Open 7.1 items
Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. Usernames limited in length Yeah, they are. ;-) If this is referring to pg_passwd, I just had a closer look and it's really a desaster. Both password and username as well as line length and file length (in lines) have arbitrary limits, sometimes not even consistent ones. To fix this to a point where one is confident that everything works one essentially would have to rewrite the whole thing. Does pg_dump preserve COMMENTs? Sure Fix ipcclean on Linux Consider it done. Merge global and template BKI files? Not this release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates. Could someone please review and
commit them if they look ok? (I'm now in US and have only very
expensive internet connection through an international phone call to
Japan in a hotel! Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.) Or I could commit after going back
to Japan planned on Feb 2 if that's not too late.
However I have not address what Tom Lane said yet(actually I do not
understand what he says).
The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...
regards, tom lane
Index: common.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/bin/pg_dump/common.c,v
retrieving revision 1.49
diff -c -r1.49 common.c
*** common.c2001/01/12 15:41:29 1.49
--- common.c2001/01/21 01:38:48
***
*** 86,95
}
}
! /* should never get here */
! fprintf(stderr, "failed sanity check, type with oid %s was not found\n",
! oid);
! exit(2);
}
/*
--- 86,93
}
}
! /* no suitable type name was found */
! return(NULL);
}
/*
***
*** 114,120
/* should never get here */
fprintf(stderr, "failed sanity check, opr with oid %s was not found\n",
oid);
! exit(2);
}
--- 112,120
/* should never get here */
fprintf(stderr, "failed sanity check, opr with oid %s was not found\n",
oid);
!
! /* no suitable operator name was found */
! return(NULL);
}
*** pg_dump.c.orig Fri Jan 26 06:56:09 2001
--- pg_dump.c Fri Jan 26 06:35:26 2001
***
*** 2928,2933
--- 2928,2942
char *elemType;
elemType = findTypeByOid(tinfo, numTypes, tinfo[i].typelem,
zeroAsOpaque);
+ if (elemType == NULL)
+ {
+ fprintf(stderr, "Notice: type for oid %s is not
+dumped.\n",
+ tinfo[i].typelem);
+ resetPQExpBuffer(q);
+ resetPQExpBuffer(delq);
+ continue;
+ }
+
appendPQExpBuffer(q, ", element = %s, delimiter = ", elemType);
formatStringLiteral(q, tinfo[i].typdelim);
}
***
*** 3086,3091
--- 3095,3101
char*listSep;
char*listSepComma = ",";
char*listSepNone = "";
+ char*rettypename;
if (finfo[i].dumped)
return;
***
*** 3147,3152
--- 3157,3177
char*typname;
typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j],
zeroAsOpaque);
+ if (typname == NULL)
+ {
+ fprintf(stderr, "Notice: function \"%s\" is not dumped.\n",
+ finfo[i].proname);
+
+ fprintf(stderr, "Reason: the %d th argument type name (oid %s)
+not found.\n",
+ j, finfo[i].argtypes[j]);
+ resetPQExpBuffer(q);
+ resetPQExpBuffer(fn);
+ resetPQExpBuffer(delqry);
+ resetPQExpBuffer(fnlist);
+ resetPQExpBuffer(asPart);
+ return;
+ }
+
appendPQExpBuffer(fn, "%s%s",
(j 0) ? "," : "",
typname);
***
*** 3159,3169
resetPQExpBuffer(delqry);
appendPQExpBuffer(delqry, "DROP FUNCTION %s;\n", fn-data );
resetPQExpBuffer(q);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", fn-data );
appendPQExpBuffer(q, "RETURNS %s%s %s LANGUAGE ",
(finfo[i].retset) ? "SETOF " : "",
! findTypeByOid(tinfo, numTypes,
finfo[i].prorettype, zeroAsOpaque),
asPart-data);
formatStringLiteral(q, func_lang);
--- 3184,3211
resetPQExpBuffer(delqry);
appendPQExpBuffer(delqry, "DROP FUNCTION %s;\n", fn-data );
+ rettypename = findTypeByOid(tinfo, numTypes, finfo[i].prorettype,
+zeroAsOpaque);
+
+ if (rettypename == NULL)
+ {
+
Re: [HACKERS] Open 7.1 items
Peter Eisentraut wrote: Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. What does this item mean ? Usernames limited in length Yeah, they are. ;-) If this is referring to pg_passwd, I just had a closer look and it's really a desaster. Both password and username as well as line length and file length (in lines) have arbitrary limits, sometimes not even consistent ones. To fix this to a point where one is confident that everything works one essentially would have to rewrite the whole thing. Does pg_dump preserve COMMENTs? Sure Fix ipcclean on Linux Consider it done. Merge global and template BKI files? Not this release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
Sorry for my previous incomplete posting. Peter Eisentraut wrote: Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. What does this item mean ? Is it the following ? begin; insert into pk (id) values (1); update(delete from) pk where id=1; ERROR: triggered data change violation on relation pk" If so, isn't it a simple bug ? Regards, Hiroshi Inoue
Re: [HACKERS] Open 7.1 items
haven't seen it posted to hackers, or, if I did, I didn't clue into it ...
and just checked to see if maybe it was waiting for approval due to size,
and nothing in the queue ...
posting it here is easier to respond to ...
On Wed, 24 Jan 2001, Bruce Momjian wrote:
I have about 20 open 7.1 items that I need to get resolved before I can
start getting the doc TODO list started. The issues relate to JDBC,
ODBC, and lots of other stuff that need to be settled before we can
finalize 7.1.
They can not be easily summarized in one line. You really have to see
the whole email to understand the issues.
How do people want to do this? I can post them to hackers, or put them
on my web site. I posted them to hackers during the past few days, but
many went unanswered. These are all relatively new from the past few
months.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] Open 7.1 items
I have trickled the emails as I reviewed them, asking for comments. It
was not one big email.
haven't seen it posted to hackers, or, if I did, I didn't clue into it ...
and just checked to see if maybe it was waiting for approval due to size,
and nothing in the queue ...
posting it here is easier to respond to ...
On Wed, 24 Jan 2001, Bruce Momjian wrote:
I have about 20 open 7.1 items that I need to get resolved before I can
start getting the doc TODO list started. The issues relate to JDBC,
ODBC, and lots of other stuff that need to be settled before we can
finalize 7.1.
They can not be easily summarized in one line. You really have to see
the whole email to understand the issues.
How do people want to do this? I can post them to hackers, or put them
on my web site. I posted them to hackers during the past few days, but
many went unanswered. These are all relatively new from the past few
months.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
On Wed, 24 Jan 2001, Bruce Momjian wrote: It has to be done separately because you need to see the full content and reply to each individually. Also, they go to different lists sometimes. Pretty confusing. Could you post a list of open issues where each has just a number, heading (optional) and link to an email in some mailing-list archive ? Not really. I don't have time to make a web site out of this thing. :-) If they were previously sent to the lists, there should be a link in the archives to point ppl to, no? :0 Sure, but this is hard enough. Finding them is even harder. May as well read the email rather than link to a web page. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: I have trickled the emails as I reviewed them, asking for comments. It was not one big email. ... They can not be easily summarized in one line. You really have to see the whole email to understand the issues. How do people want to do this? I can post them to hackers, or put them on my web site. I posted them to hackers during the past few days, but many went unanswered. These are all relatively new from the past few months. I guess that having _one_ document with all of them would get much more attention. It could be just copy and paste from the e-mails, numbered to be easily referred to. Not everybody here reads _every_ mail on the list, even if it is from you ;) --- Hannu
Re: [HACKERS] Open 7.1 items
They can not be easily summarized in one line. You really have to see the whole email to understand the issues. How do people want to do this? I can post them to hackers, or put them on my web site. I posted them to hackers during the past few days, but many went unanswered. These are all relatively new from the past few months. I guess that having _one_ document with all of them would get much more attention. It could be just copy and paste from the e-mails, numbered to be easily referred to. Not everybody here reads _every_ mail on the list, even if it is from you ;) It has to be done separately because you need to see the full content and reply to each individually. Also, they go to different lists sometimes. Pretty confusing. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
It has to be done separately because you need to see the full content and reply to each individually. Also, they go to different lists sometimes. Pretty confusing. Could you post a list of open issues where each has just a number, heading (optional) and link to an email in some mailing-list archive ? Not really. I don't have time to make a web site out of this thing. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: On Wed, 24 Jan 2001, Bruce Momjian wrote: It has to be done separately because you need to see the full content and reply to each individually. Also, they go to different lists sometimes. Pretty confusing. Could you post a list of open issues where each has just a number, heading (optional) and link to an email in some mailing-list archive ? Not really. I don't have time to make a web site out of this thing. :-) If they were previously sent to the lists, there should be a link in the archives to point ppl to, no? :0 Sure, but this is hard enough. Finding them is even harder. IIRC you complained that there are 20 open issues that needed to be resolved befor releasing 7.1, no? Just to start discussing them, we should need a more or less closed list of issues. Or was the original posting (the one that started this thread) just a comment about how hard life is ;) ;) You can't reasonably expect people to read all e-mail from last few weeks (probably a few thousands) and spot the same items as you. May as well read the email rather than link to a web page. Still it would be good to have a "TODO before 7.1 relese" - Hannu
Re: [HACKERS] Open 7.1 items
You can't reasonably expect people to read all e-mail from last few weeks (probably a few thousands) and spot the same items as you. May as well read the email rather than link to a web page. Still it would be good to have a "TODO before 7.1 relese" I send each article to the appropriate list with a comment at the top asking for assistance. I can't boild down many of these items into short descriptions. People need to see the detail of the emails. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: You can't reasonably expect people to read all e-mail from last few weeks (probably a few thousands) and spot the same items as you. May as well read the email rather than link to a web page. Still it would be good to have a "TODO before 7.1 relese" I send each article to the appropriate list with a comment at the top asking for assistance. I can't boild down many of these items into short descriptions. People need to see the detail of the emails. But maybe we could agree on something in Subject:, maybe [TODO - 7.1] so that it is immediately clear it's urgent ? - Hannu
Re: [HACKERS] Open 7.1 items
On Wed, 24 Jan 2001, Hannu Krosing wrote: Bruce Momjian wrote: You can't reasonably expect people to read all e-mail from last few weeks (probably a few thousands) and spot the same items as you. May as well read the email rather than link to a web page. Still it would be good to have a "TODO before 7.1 relese" I send each article to the appropriate list with a comment at the top asking for assistance. I can't boild down many of these items into short descriptions. People need to see the detail of the emails. But maybe we could agree on something in Subject:, maybe [TODO - 7.1] so that it is immediately clear it's urgent ? Sounds reasonable to me ...
[HACKERS] Open 7.1 items
Here are my open 7.1 items. Thanks for shrinking the list so far. --- FreeBSD locale bug Reorder INSERT firing in rules Philip Warner UPDATE crash JDBC LargeObject short read return value missing SELECT cash_out(1) crashes all backends LAZY VACUUM FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" Usernames limited in length Does pg_dump preserve COMMENTs? Failure of nested cursors in JDBC JDBC setMaxRows() is global variable affecting other objects Does JDBC Makefile need current dir? Fix for pg_dump of bad system tables Steve Howe failure query with rules ODBC/JDBC not disconnecting properly? Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux Merge global and template BKI files? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
On Wed, 24 Jan 2001, Bruce Momjian wrote: Here are my open 7.1 items. Thanks for shrinking the list so far. --- FreeBSD locale bug AFAIK, Tom have fixed it, if this bug is about -funsigned-char Reorder INSERT firing in rules Philip Warner UPDATE crash JDBC LargeObject short read return value missing SELECT cash_out(1) crashes all backends LAZY VACUUM FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" Usernames limited in length Does pg_dump preserve COMMENTs? Failure of nested cursors in JDBC JDBC setMaxRows() is global variable affecting other objects Does JDBC Makefile need current dir? Fix for pg_dump of bad system tables Steve Howe failure query with rules ODBC/JDBC not disconnecting properly? Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux Merge global and template BKI files? Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
[HACKERS] Open 7.1 items
I have about 20 open 7.1 items that I need to get resolved before I can start getting the doc TODO list started. The issues relate to JDBC, ODBC, and lots of other stuff that need to be settled before we can finalize 7.1. They can not be easily summarized in one line. You really have to see the whole email to understand the issues. How do people want to do this? I can post them to hackers, or put them on my web site. I posted them to hackers during the past few days, but many went unanswered. These are all relatively new from the past few months. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
