Thread
-
Current sources?
David Gould <dg@illustra.com> — 1998-05-22T07:33:16Z
I have seen a few patches fly by on the list, but when I checked the last snapshot was dated May 4th. Unhappily, CVSup is not working for me right now. Is there a later snapshot, or should I just work with this one? Oh, and who should I really direct this kind of "site admin" question to anyway? Thanks -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 "Of course, someone who knows more about this will correct me if I'm wrong, and someone who knows less will correct me if I'm right." --David Palmer (palmer@tybalt.caltech.edu) -
Re: [HACKERS] Current sources?
Marc G. Fournier <scrappy@hub.org> — 1998-05-22T11:54:11Z
On Fri, 22 May 1998, David Gould wrote: > > I have seen a few patches fly by on the list, but when I checked the > last snapshot was dated May 4th. Unhappily, CVSup is not working for me > right now. Is there a later snapshot, or should I just work with this one? snapshot's only happen once a week unless in a BETA freeze...what is wrong with CVSup for you though? >Oh, and who should I really direct this kind of "site admin" question to > anyway? Me...but the list works too, since then everyone knows what is going on (for those new *grin*)
-
Re: [HACKERS] Current sources?
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-22T14:17:33Z
> > > I have seen a few patches fly by on the list, but when I checked the > last snapshot was dated May 4th. Unhappily, CVSup is not working for me > right now. Is there a later snapshot, or should I just work with this one? > > Oh, and who should I really direct this kind of "site admin" question to > anyway? > Marc, Mr. scrappy, scrappy@hub.org. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Current sources?
Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-22T19:30:47Z
The Hermit Hacker <scrappy@hub.org> writes: > snapshot's only happen once a week unless in a BETA freeze...what > is wrong with CVSup for you though? CVSup can only be used on a few platforms, and is a hell of a big job to port to new ones, because you have to begin by porting a Modula-3 compiler. Decidedly non-trivial. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
-
Re: [HACKERS] Current sources?
Marc G. Fournier <scrappy@hub.org> — 1998-05-22T23:19:23Z
On 22 May 1998, Tom Ivar Helbekkmo wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > > snapshot's only happen once a week unless in a BETA freeze...what > > is wrong with CVSup for you though? > > CVSup can only be used on a few platforms, and is a hell of a big job > to port to new ones, because you have to begin by porting a Modula-3 > compiler. Decidedly non-trivial. I've tried to get anonCVS working, and am still working on it, but, for some odd reason, it isn't working as expected, even with following the instructions laid out in several FAQs :( Try this: cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot login - password of 'postgresql' cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot co pgsql And tell me what it comes up with...it might just be me *shrug* Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Current sources?
Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-23T13:29:12Z
The Hermit Hacker <scrappy@hub.org> writes: > Try this: > > cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot login > - password of 'postgresql' > cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot co pgsql > > And tell me what it comes up with...it might just be me *shrug* Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and it's pulling the PostgreSQL distribution in as I type. For some reason all the files are mode 666 (directories are 755, as per UMASK), but that's just a minor nit I'll figure out or work around. Is logging in really necessary, though? This is the first time I ever use anonymous CVS, but I'd assumed it would "just work", without any interactive specification of passwords... -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
-
Re: [HACKERS] Current sources?
Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-23T14:26:21Z
Tom Ivar Helbekkmo <tih+mail@Hamartun.Priv.NO> writes: > Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and > it's pulling the PostgreSQL distribution in as I type. The "cvs checkout" worked fine, and a "cvs update" afterwards scanned the repository and confirmed I was up to date. Looks good! :-) -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
-
Re: [HACKERS] Current sources?
Marc G. Fournier <scrappy@hub.org> — 1998-05-23T16:33:43Z
On 23 May 1998, Tom Ivar Helbekkmo wrote: > Tom Ivar Helbekkmo <tih+mail@Hamartun.Priv.NO> writes: > > > Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and > > it's pulling the PostgreSQL distribution in as I type. > > The "cvs checkout" worked fine, and a "cvs update" afterwards scanned > the repository and confirmed I was up to date. Looks good! :-) Odd...it was doing a 'second checkout' that screwed me, where i didn't think it worked...try doing 'cvs -d <> checkout -P pgsql' and tell me what that does... And, yes, password is required... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Current sources?
Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-23T18:12:24Z
The Hermit Hacker <scrappy@hub.org> writes: > Odd...it was doing a 'second checkout' that screwed me, where > i didn't think it worked...try doing 'cvs -d <> checkout -P pgsql' > and tell me what that does... I assume "<>" means "the same path as before", in which case this is just doing a new checkout on top of an old one, right? I've got one of those running now, to see what happens, but I don't see why you would want do do this. "cvs update" is the way it's supposed to be done, once you've got the tree checked out. I know _that_ worked. Right now, the second "cvs checkout" is running, and there seems to be much communication going on, but no new downloading of files I already have. Pretty much like during the "cvs update", that is. We'll see. Ah, yes. Here we go. This looks just like the "cvs update" pass. In fact, it seems that a second checkout on top of an existing one turns out to behave just like a (more proper) update from within the tree. Done now, worked fine. I'm starting to look forward to when the CVS source tree gets into a buildable state again! This could be a comfortable way of keeping up to date with the current sources. Here's hoping you find a good solution to the s_lock.h misunderstandings soon... :-) > And, yes, password is required... I've found where it's stashed, now. I guess that means you only need to supply it once, to do the initial checkout, and after that you won't have to worry about it. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
-
Re: [HACKERS] Current sources?
Marc G. Fournier <scrappy@hub.org> — 1998-05-23T19:38:23Z
On 23 May 1998, Tom Ivar Helbekkmo wrote: > Ah, yes. Here we go. This looks just like the "cvs update" pass. In > fact, it seems that a second checkout on top of an existing one turns > out to behave just like a (more proper) update from within the tree. > > Done now, worked fine. Odd, must be a problem with the machine I was trying to run it from then *shrug* Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Current sources?
Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-24T09:13:14Z
I wrote: > I'm starting to look forward to when the CVS source tree gets into a > buildable state again! This could be a comfortable way of keeping > up to date with the current sources. Here's hoping you find a good > solution to the s_lock.h misunderstandings soon... :-) A closer look shows that you've actually got it worked out, except that the ugly hack for Sparcs running BSD now has broken completely. It used to work when it was in s_lock.h, but in a separately compiled file, it doesn't. (It relies on an entry point declared inside asm() within an unused function that's explicitly declared static.) I just replaced it with the simpler one for SparcLinux, and it's OK. On the weird side, after I updated to the current sources, the backend dies on me whenever I try to delete a database, whether from psql with 'drop database test' or from the command line with 'destroydb test'. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
-
Re: [HACKERS] Current sources?
David Gould <dg@illustra.com> — 1998-05-25T01:38:44Z
Tom Ivar Helbekkmo wrote: > > > I'm starting to look forward to when the CVS source tree gets into a > > buildable state again! This could be a comfortable way of keeping > > up to date with the current sources. Here's hoping you find a good > > solution to the s_lock.h misunderstandings soon... :-) > > A closer look shows that you've actually got it worked out, except > that the ugly hack for Sparcs running BSD now has broken completely. > It used to work when it was in s_lock.h, but in a separately compiled > file, it doesn't. (It relies on an entry point declared inside asm() > within an unused function that's explicitly declared static.) Ooops, sorry about that. I guess I should have added a ".globl tas" or whatever the native asm phrase for globalizing an entry point is and then it would have worked as I intended. > I just replaced it with the simpler one for SparcLinux, and it's OK. This is a very nice way to do this. In general, if we can count on having GCC we should use the GCC inlines. Hmmmm, on that note, the current sources are factored: #if defined(linux) #if defined(x86) // x86 code #else if defined(sparc) // sparc code #endif #else // all non linux ... #endif I think that the real commonality might better be expressed as: #if defined(gcc) // all gcc variants #else // no gcc #endif As GCC has a unique (but common to gcc!) "asm" facility. This would allow all the free unixes and many of the comercial ones to share the same asm implementation which should make it easier to get it right on all the platforms. Since I am planning another revision, does anyone object to this? > On the weird side, after I updated to the current sources, the backend > dies on me whenever I try to delete a database, whether from psql with > 'drop database test' or from the command line with 'destroydb test'. Try making the 's_lock_test' target in src/backend/storage/buffer/Makefile. It will let you be sure that spinlocks are working. Just btw, I have been doing some testing based on Bruce's reservations about the inline vs call implementation of spinlocks, and will be posting an updated set of patches and the results of my testing "real soon now". Now that I have at least anoncvs access to the current tree, I think I can do this with fewer iterations (crossing fingers...). David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 "Of course, someone who knows more about this will correct me if I'm wrong, and someone who knows less will correct me if I'm right." --David Palmer (palmer@tybalt.caltech.edu) -
Re: [HACKERS] Current sources?
Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-25T03:26:47Z
dg@illustra.com (David Gould) writes: > Try making the 's_lock_test' target in > src/backend/storage/buffer/Makefile. It will let you be sure that > spinlocks are working. This is how it looks like here (NetBSD/sparc 1.3, GCC 1.7.2.2), with the broken TAS support replaced with that from SparcLinux: | barsoom# gmake s_lock_test | gcc -I../../../include -I../../../backend -I/usr/local/include -O2 -pipe -Wall -Wmissing-prototypes -I../.. -DS_LOCK_TEST=1 -g s_lock.c -o s_lock_test | s_lock.c: In function `main': | s_lock.c:313: warning: implicit declaration of function `select' | ./s_lock_test | S_LOCK_TEST: this will hang for a few minutes and then abort | with a 'stuck spinlock' message if S_LOCK() | and TAS() are working. | | FATAL: s_lock(00004168) at s_lock.c:324, stuck spinlock. Aborting. | | FATAL: s_lock(00004168) at s_lock.c:324, stuck spinlock. Aborting. | gmake: *** [s_lock_test] Abort trap (core dumped) | gmake: *** Deleting file `s_lock_test' | barsoom# ...and it did take a couple of minutes (didn't time it, though), so I guess it works, right? -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
-
Re: [HACKERS] Current sources?
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-25T03:59:24Z
> This is a very nice way to do this. In general, if we can count on having > GCC we should use the GCC inlines. > > Hmmmm, on that note, the current sources are factored: > > #if defined(linux) > #if defined(x86) > // x86 code > #else if defined(sparc) > // sparc code > #endif > #else > // all non linux > ... > #endif > > I think that the real commonality might better be expressed as: > > #if defined(gcc) > // all gcc variants > #else > // no gcc > #endif > > As GCC has a unique (but common to gcc!) "asm" facility. This would allow > all the free unixes and many of the comercial ones to share the same > asm implementation which should make it easier to get it right on all the > platforms. > > Since I am planning another revision, does anyone object to this? Sounds great. > > > On the weird side, after I updated to the current sources, the backend > > dies on me whenever I try to delete a database, whether from psql with > > 'drop database test' or from the command line with 'destroydb test'. > > Try making the 's_lock_test' target in src/backend/storage/buffer/Makefile. > It will let you be sure that spinlocks are working. > > Just btw, I have been doing some testing based on Bruce's reservations about > the inline vs call implementation of spinlocks, and will be posting an updated > set of patches and the results of my testing "real soon now". > > Now that I have at least anoncvs access to the current tree, I think I can > do this with fewer iterations (crossing fingers...). -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] Current sources?
David Gould <dg@illustra.com> — 1998-05-25T19:23:46Z
tih wrote: > > > I'm starting to look forward to when the CVS source tree gets into a > > buildable state again! This could be a comfortable way of keeping > > up to date with the current sources. Here's hoping you find a good > > solution to the s_lock.h misunderstandings soon... :-) ... > On the weird side, after I updated to the current sources, the backend > dies on me whenever I try to delete a database, whether from psql with > 'drop database test' or from the command line with 'destroydb test'. > > -tih Ok, I think I have found the source of the dropconns on "delete" querys that are causing the current problem. The change listed below sets tupType to the junkFilter (whatever that is) jf_cleanTupType unconditionally. This makes a SEGV later as the tupType ends up NULL. Here is what CVS says: --------------- revision 1.46 date: 1998/05/21 03:53:50; author: scrappy; state: Exp; lines: +6 -4 From: David Hartwig <daveh@insightdist.com> Here is a patch to remove the requirement that ORDER/GROUP BY clause identifiers be included in the target list. -------------- I do not believe that this could ever have passed regression. Do we have the whole patch to back out, or do we need to just "fix what we have now"? Also, perhaps we need to be more selective about checkins? Here is the source containing the problem: src/backend/executor/execMain.c in InitPlan() at about line 515 /* ---------------- * now that we have the target list, initialize the junk filter * if this is a REPLACE or a DELETE query. * We also init the junk filter if this is an append query * (there might be some rule lock info there...) * NOTE: in the future we might want to initialize the junk * filter for all queries. * ---------------- * SELECT added by daveh@insightdist.com 5/20/98 to allow * ORDER/GROUP BY have an identifier missing from the target. */ if (operation == CMD_UPDATE || operation == CMD_DELETE || operation == CMD_INSERT || operation == CMD_SELECT) { JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList); estate->es_junkFilter = j; >>>> tupType = j->jf_cleanTupType; /* Added by daveh@insightdist.com 5/20/98 */ } else estate->es_junkFilter = NULL; Here is my debug transcript for "drop database regression" (gdb) where #0 InitPlan (operation=CMD_DELETE, parseTree=0x81b68f8, plan=0x81ba468, estate=0x81ba668) at execMain.c:527 #1 0x8098017 in ExecutorStart (queryDesc=0x81ba640, estate=0x81ba668) at execMain.c:128 #2 0x80e24d9 in ProcessQueryDesc (queryDesc=0x81ba640) at pquery.c:285 #3 0x80e258e in ProcessQuery (parsetree=0x81b68f8, plan=0x81ba468, argv=0x0, typev=0x0, nargs=0, dest=Remote) at pquery.c:378 #4 0x80e13b0 in pg_exec_query_dest ( query_string=0xbfffd5f8 "delete from pg_database where pg_database.oid = '18080'::oid", argv=0x0, typev=0x0, nargs=0, dest=Remote) at postgres.c:702 #5 0x80e12b2 in pg_exec_query ( query_string=0xbfffd5f8 "delete from pg_database where pg_database.oid = '18080'::oid", argv=0x0, typev=0x0, nargs=0) at postgres.c:601 #6 0x8096596 in destroydb (dbname=0x81b2558 "regression") at dbcommands.c:136 #7 0x80e304c in ProcessUtility (parsetree=0x81b2578, dest=Remote) at utility.c:570 #8 0x80e1350 in pg_exec_query_dest ( query_string=0xbfffd928 "drop database regression;", argv=0x0, typev=0x0, nargs=0, dest=Remote) at postgres.c:656 #9 0x80e12b2 in pg_exec_query ( query_string=0xbfffd928 "drop database regression;", argv=0x0, typev=0x0, nargs=0) at postgres.c:601 #10 0x80e2001 in PostgresMain (argc=9, argv=0xbffff960) at postgres.c:1417 #11 0x80a7707 in main (argc=9, argv=0xbffff960) at main.c:105 530 JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList); 531 estate->es_junkFilter = j; (gdb) p j $7 = (JunkFilter *) 0x81bb2c8 (gdb) p *j $8 = {type = T_JunkFilter, jf_targetList = 0x81ba600, jf_length = 1, jf_tupType = 0x81bb238, jf_cleanTargetList = 0x0, jf_cleanLength = 0, jf_cleanTupType = 0x0, jf_cleanMap = 0x0} (gdb) n 533 tupType = j->jf_cleanTupType; /* Added by daveh@insightdist.com 5/20/98 */ (gdb) p tupType $9 = (struct tupleDesc *) 0x81baf18 (gdb) n 534 } (gdb) p tupType $10 = (struct tupleDesc *) 0x0 (gdb) n 542 intoRelationDesc = (Relation) NULL; (gdb) n 544 if (operation == CMD_SELECT) (gdb) n 588 estate->es_into_relation_descriptor = intoRelationDesc; (gdb) n 600 return tupType; Returns NULL to ExecutorStart who then pukes. -dg David Gould dg@illustra.com 510.536.1443 (h) 510.628.3783 (w) or davidg@dnai.com 510.305.9468 (Bat phone) -- A child of five could understand this! Fetch me a child of five. -
Re: [HACKERS] Current sources?
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-25T22:30:16Z
> -------------- > > I do not believe that this could ever have passed regression. Do we have > the whole patch to back out, or do we need to just "fix what we have now"? > > Also, perhaps we need to be more selective about checkins? Not sure. Marc and I reviewed it, and it looked very good. In fact, I would like to see more of such patches, of course, without the destroydb problem, but many patches have little quirks the author could not have anticipated. > { > JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList); > estate->es_junkFilter = j; > >>>> tupType = j->jf_cleanTupType; /* Added by daveh@insightdist.com 5/20/98 */ > } > else > estate->es_junkFilter = NULL; > > Here is my debug transcript for "drop database regression" Here is the original patch. I got it with the command: $ pgcvs diff -c -D'05/21/1998 03:00:00 GMT' -D'05/21/1998 04:00:00 GMT' pgcvs on my machines does postgresql cvs for me. --------------------------------------------------------------------------- Index: backend/executor/execMain.c =================================================================== RCS file: /usr/local/cvsroot/pgsql/src/backend/executor/execMain.c,v retrieving revision 1.45 retrieving revision 1.46 diff -c -r1.45 -r1.46 *** execMain.c 1998/02/27 08:43:52 1.45 --- execMain.c 1998/05/21 03:53:50 1.46 *************** *** 26,32 **** * * * IDENTIFICATION ! * $Header: /usr/local/cvsroot/pgsql/src/backend/executor/execMain.c,v 1.45 1998/02/27 08:43:52 vadim Exp $ * *------------------------------------------------------------------------- */ --- 26,32 ---- * * * IDENTIFICATION ! * $Header: /usr/local/cvsroot/pgsql/src/backend/executor/execMain.c,v 1.46 1998/05/21 03:53:50 scrappy Exp $ * *------------------------------------------------------------------------- */ *************** *** 521,534 **** * NOTE: in the future we might want to initialize the junk * filter for all queries. * ---------------- */ if (operation == CMD_UPDATE || operation == CMD_DELETE || ! operation == CMD_INSERT) { - JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList); - estate->es_junkFilter = j; } else estate->es_junkFilter = NULL; --- 521,536 ---- * NOTE: in the future we might want to initialize the junk * filter for all queries. * ---------------- + * SELECT added by daveh@insightdist.com 5/20/98 to allow + * ORDER/GROUP BY have an identifier missing from the target. */ if (operation == CMD_UPDATE || operation == CMD_DELETE || ! operation == CMD_INSERT || operation == CMD_SELECT) { JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList); estate->es_junkFilter = j; + + tupType = j->jf_cleanTupType; /* Added by daveh@insightdist.com 5/20/98 */ } else estate->es_junkFilter = NULL; Index: backend/parser/parse_clause.c =================================================================== RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/parse_clause.c,v retrieving revision 1.15 retrieving revision 1.16 diff -c -r1.15 -r1.16 *** parse_clause.c 1998/03/31 04:43:53 1.15 --- parse_clause.c 1998/05/21 03:53:50 1.16 *************** *** 7,13 **** * * * IDENTIFICATION ! * $Header: /usr/local/cvsroot/pgsql/src/backend/parser/parse_clause.c,v 1.15 1998/03/31 04:43:53 momjian Exp $ * *------------------------------------------------------------------------- */ --- 7,13 ---- * * * IDENTIFICATION ! * $Header: /usr/local/cvsroot/pgsql/src/backend/parser/parse_clause.c,v 1.16 1998/05/21 03:53:50 scrappy Exp $ * *------------------------------------------------------------------------- */ *************** *** 182,187 **** --- 182,218 ---- } } } + + /* BEGIN add missing target entry hack. + * + * Prior to this hack, this function returned NIL if no target_result. + * Thus, ORDER/GROUP BY required the attributes be in the target list. + * Now it constructs a new target entry which is appended to the end of + * the target list. This target is set to be resjunk = TRUE so that + * it will not be projected into the final tuple. + * daveh@insightdist.com 5/20/98 + */ + if ( ! target_result) { + List *p_target = tlist; + Ident *missingTargetId = (Ident *)makeNode(Ident); + TargetEntry *tent = makeNode(TargetEntry); + + /* Fill in the constructed Ident node */ + missingTargetId->type = T_Ident; + missingTargetId->name = palloc(strlen(sortgroupby->name) + 1); + strcpy(missingTargetId->name, sortgroupby->name); + + transformTargetId(pstate, missingTargetId, tent, missingTargetId->name, TRUE); + + /* Add to the end of the target list */ + while (lnext(p_target) != NIL) { + p_target = lnext(p_target); + } + lnext(p_target) = lcons(tent, NIL); + target_result = tent; + } + /* END add missing target entry hack. */ + return target_result; } *************** *** 203,212 **** Resdom *resdom; restarget = find_targetlist_entry(pstate, lfirst(grouplist), targetlist); - - if (restarget == NULL) - elog(ERROR, "The field being grouped by must appear in the target list"); - grpcl->entry = restarget; resdom = restarget->resdom; grpcl->grpOpoid = oprid(oper("<", --- 234,239 ---- *************** *** 262,270 **** restarget = find_targetlist_entry(pstate, sortby, targetlist); - if (restarget == NULL) - elog(ERROR, "The field being ordered by must appear in the target list"); - sortcl->resdom = resdom = restarget->resdom; sortcl->opoid = oprid(oper(sortby->useOp, resdom->restype, --- 289,294 ---- Index: backend/parser/parse_target.c =================================================================== RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/parse_target.c,v retrieving revision 1.12 retrieving revision 1.13 diff -c -r1.12 -r1.13 *** parse_target.c 1998/05/09 23:29:54 1.12 --- parse_target.c 1998/05/21 03:53:51 1.13 *************** *** 7,13 **** * * * IDENTIFICATION ! * $Header: /usr/local/cvsroot/pgsql/src/backend/parser/parse_target.c,v 1.12 1998/05/09 23:29:54 thomas Exp $ * *------------------------------------------------------------------------- */ --- 7,13 ---- * * * IDENTIFICATION ! * $Header: /usr/local/cvsroot/pgsql/src/backend/parser/parse_target.c,v 1.13 1998/05/21 03:53:51 scrappy Exp $ * *------------------------------------------------------------------------- */ *************** *** 52,57 **** --- 52,102 ---- Oid type_id, Oid attrtype); + + /* + * transformTargetId - transforms an Ident Node to a Target Entry + * Created this a function to allow the ORDER/GROUP BY clause be able + * to construct a TargetEntry from an Ident. + * + * resjunk = TRUE will hide the target entry in the final result tuple. + * daveh@insightdist.com 5/20/98 + */ + void + transformTargetId(ParseState *pstate, + Ident *ident, + TargetEntry *tent, + char *resname, + int16 resjunk) + { + Node *expr; + Oid type_id; + int16 type_mod; + + /* + * here we want to look for column names only, not + * relation names (even though they can be stored in + * Ident nodes, too) + */ + expr = transformIdent(pstate, (Node *) ident, EXPR_COLUMN_FIRST); + type_id = exprType(expr); + if (nodeTag(expr) == T_Var) + type_mod = ((Var *) expr)->vartypmod; + else + type_mod = -1; + tent->resdom = makeResdom((AttrNumber) pstate->p_last_resno++, + (Oid) type_id, + type_mod, + resname, + (Index) 0, + (Oid) 0, + resjunk); + + tent->expr = expr; + return; + } + + + /* * transformTargetList - * turns a list of ResTarget's into a list of TargetEntry's *************** *** 71,106 **** { case T_Ident: { - Node *expr; - Oid type_id; - int16 type_mod; char *identname; char *resname; identname = ((Ident *) res->val)->name; handleTargetColname(pstate, &res->name, NULL, identname); - - /* - * here we want to look for column names only, not - * relation names (even though they can be stored in - * Ident nodes, too) - */ - expr = transformIdent(pstate, (Node *) res->val, EXPR_COLUMN_FIRST); - type_id = exprType(expr); - if (nodeTag(expr) == T_Var) - type_mod = ((Var *) expr)->vartypmod; - else - type_mod = -1; resname = (res->name) ? res->name : identname; ! tent->resdom = makeResdom((AttrNumber) pstate->p_last_resno++, ! (Oid) type_id, ! type_mod, ! resname, ! (Index) 0, ! (Oid) 0, ! 0); ! ! tent->expr = expr; break; } case T_ParamNo: --- 116,128 ---- { case T_Ident: { char *identname; char *resname; identname = ((Ident *) res->val)->name; handleTargetColname(pstate, &res->name, NULL, identname); resname = (res->name) ? res->name : identname; ! transformTargetId(pstate, (Ident*)res->val, tent, resname, FALSE); break; } case T_ParamNo: Index: include/parser/parse_target.h =================================================================== RCS file: /usr/local/cvsroot/pgsql/src/include/parser/parse_target.h,v retrieving revision 1.4 retrieving revision 1.5 diff -c -r1.4 -r1.5 *** parse_target.h 1998/02/26 04:42:49 1.4 --- parse_target.h 1998/05/21 03:53:51 1.5 *************** *** 6,12 **** * * Copyright (c) 1994, Regents of the University of California * ! * $Id: parse_target.h,v 1.4 1998/02/26 04:42:49 momjian Exp $ * *------------------------------------------------------------------------- */ --- 6,12 ---- * * Copyright (c) 1994, Regents of the University of California * ! * $Id: parse_target.h,v 1.5 1998/05/21 03:53:51 scrappy Exp $ * *------------------------------------------------------------------------- */ *************** *** 24,28 **** --- 24,30 ---- extern List *transformTargetList(ParseState *pstate, List *targetlist); extern List *makeTargetNames(ParseState *pstate, List *cols); + extern void transformTargetId(ParseState *pstate, Ident *ident, + TargetEntry *tent, char *resname, int16 resjunk); #endif /* PARSE_TARGET_H */ -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h) -
Re: [HACKERS] Current sources?
Marc G. Fournier <scrappy@hub.org> — 1998-05-25T22:43:26Z
On Mon, 25 May 1998, David Gould wrote: > Ok, I think I have found the source of the dropconns on "delete" querys > that are causing the current problem. The change listed below sets > tupType to the junkFilter (whatever that is) jf_cleanTupType unconditionally. > This makes a SEGV later as the tupType ends up NULL. > > Here is what CVS says: > --------------- > revision 1.46 > date: 1998/05/21 03:53:50; author: scrappy; state: Exp; lines: +6 -4 > > From: David Hartwig <daveh@insightdist.com> > > Here is a patch to remove the requirement that ORDER/GROUP BY clause > identifiers be included in the target list. > -------------- > > I do not believe that this could ever have passed regression. Do we have > the whole patch to back out, or do we need to just "fix what we have now"? fix what we have now...if its possible... > Also, perhaps we need to be more selective about checkins? We're in an alpha/development phase here...my general opinion on that is that I'd rather someone throw in code that is 95% good, with 5% error, then nobody making a start anywhere... Until a Beta freeze, *never* expect the server to actually work...if it does, bonus. Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org