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
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)
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
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)
> 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)
> 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)
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)
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... regards, tom lane
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)
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>: > > :Do a > > : > > :GET DIAGNOSTICS SELECT PROCESSED INTO ; > > : > > :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 ; > > > May I suggest that this is the wrong syntax? It should be > > > > GET DIAGNOSTICS = 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 = 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)
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)
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)
> 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)
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)
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
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)
> >> 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: 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)
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 18:49 18/02/01 -0500, Tom Lane wrote: >Peter Eisentraut <[EMAIL PROTECTED]> writes: >> : >> :GET DIAGNOSTICS SELECT RESULT INTO ; > >> May I suggest that this is the wrong syntax? It should be > >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? Sadly, we made it up. I needed to get the SPI variables and we came up with this. I sent the patches for PROCESSED and RESULT in 1999 (I think) - pre V6.5, anyway. I had no idea that they had been applied until people started asking questions about them. >I'd be more inclined to follow the spec than Oracle, anyway. I agree. However, there is a case for keeping the 'select' version as well; you have already raised the need to handle the 'OID' case, and I can imagine there might be a few other PG-specific things we might want in the future - keeping the two separate may be a good option: 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). >if we're going to change it, we'd better do so before 7.1 release, >else we'll have a backwards-compatibility problem. *If* you accept the desirability of 'select', then this is not true. P.S. Is Jan around? He's been very quiet recently... 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 |/
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 ; > : > :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 ; > May I suggest that this is the wrong syntax? It should be > > GET DIAGNOSTICS = 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 = OID; which seems unlikely to conflict with any future spec extension. But maybe someone has a better idea. regards, tom lane
Re: [HACKERS] Open 7.1 items
At 12:15 16/02/01 -0500, Bruce Momjian wrote: > >Can someone comment on this? Seems GET DIAGNOSTICS is wrong from >Peter's reading of SQL92, and mine too. > He's quite correct. 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
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] =
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 ; > > > : > > > :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 ; > > > > > > > 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 = 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
[ 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
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
> > 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
#include
#include
#include
#include
#include
#include
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
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
> 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: > 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 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 ; > > : > > :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 ; > > > > 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 = 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 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 ; > : > :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 ; > 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: > 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: [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
> 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: [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
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
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
> 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
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
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
> * 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
* 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: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: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
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
> >> 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
> >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. 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... -- Tatsuo Ishii
Re: [HACKERS] Open 7.1 items
Hi, there! On Sat, 27 Jan 2001, Bruce Momjian wrote: > 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 > What about strange write locking of primary index element, if something that references it is changed (inserted or updated), you cannot modify in other transaction something else that references the same primary index element until first transaction ends. For example: CREATE table primtest (id integer primary key); CREATE table foreigntest1 (id integer references primtest); CREATE table foreigntest2 (id integer references primtest); INSERT INTO primtest VALUES (1); BEGIN; INSERT INTO foreigntest1 VALUES (1); -- and in other transaction: INSERT INTO foreigntest2 VALUES (1); -- blocked until COMMIT or ROLLBACK issued in first transaction. /Constantin
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
> 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
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 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
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).
...
>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
> Here are the open items for 7.1. Much shorter: + Runtime btree recovery Vadim
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: [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 <[EMAIL PROTECTED]> writes: > > Here are my open 7.1 items. Thanks for shrinking the list so far. > > > 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. > 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 > -- 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
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
> > 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
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
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
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
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
> 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)
+ {
+ fprin
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
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
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
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
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 ...
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 ... Great idea. -- 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
> 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: > > > 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
> > 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
> > > > 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
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
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: > > > > > > 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. 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 ? Hannu
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
> 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
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
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
