Re: [HACKERS] Document and/or remove unreachable code in tuptoaster.c from varvarlena patch

2007-08-05 Thread Gregory Stark

Tom Lane [EMAIL PROTECTED] writes:

 Gregory Stark [EMAIL PROTECTED] writes:
 Testers here were having a hard time constructing test cases to reach some
 lines touched by the varvarlena patch. Upon further investigation I'm
 convinced they're unreachable.

 I'm not really happy with any of this patch. ISTM that the stuff you say is
 unreachable is only so because of non-essential behavioral choices made in
 other parts of the code. If we were to change those other parts later, this
 code (after patching) would break. I'd rather leave complete coverage here
 and not make fragile assumptions; especially so since these are presumably
 not performance-critical paths.

Ok, that's true for the branches handling packed toast chunks. I thought it
was better to throw an error rather than have silently accept something which
indicates something unexpected has happened. And it was just extra useless
code for readers to slog through. 

The others I just put comments on In case the next person was as confused as I
was trying to figure out the logic. They're not especially performance
critical even though they're in the loop because they only get hit when we're
considering fields the first time.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] Document and/or remove unreachable code in tuptoaster.c from varvarlena patch

2007-08-04 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes:
 Testers here were having a hard time constructing test cases to reach some
 lines touched by the varvarlena patch. Upon further investigation I'm
 convinced they're unreachable.

I'm not really happy with any of this patch.  ISTM that the stuff you
say is unreachable is only so because of non-essential behavioral
choices made in other parts of the code.  If we were to change those
other parts later, this code (after patching) would break.  I'd rather
leave complete coverage here and not make fragile assumptions; especially
so since these are presumably not performance-critical paths.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] Document and/or remove unreachable code in tuptoaster.c from varvarlena patch

2007-07-27 Thread Gregory Stark

Sorry, meant to send the previous message to pgsql-patches.

Here's a version cut using cvs diff so it's usable with -p0

I added one more fixup. There was a silly test in toast_fetch_datum_slice()
which handled compressed datums. Returning a slice of a compressed datum is
nonsensical with toast since the resulting datum would be useless. I also
added an assertion in this function that the datum is external before we treat
it as a toast_pointer.

(Incidentally, I did eventually manage to construct a case to reach all the 
pfrees.)



tuptoaster-fixup.patch.gz
Description: Binary data



-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly