Re: how are these two strings not equal?

> > Run the two strings through
>
> > sub nicehex {
> >   my $s = $_[0];
> > ...
>
> Noone's perfect. Here is a correct version, that one cut off the last
> few characters.
>
> sub nicehex {
>   my $s = $_[0];
>   my $hex = unpack 'H*', $s;
>   $s =~ tr/\x00-\x0A/./;
>   $hex =~ s/(..)/$1 /g;
>
>   my @hex = ($hex =~ /(.{1,47}) /g);
>   my @s = ($s =~ /(.{1,16})/g);
>
>   $hex[-1] .= ' ' x (47 - length($hex[-1]));
>
>   my $res = '';
>   while (@s) {
>     $res .= shift(@hex) . '   |' .shift(@s) . "\n";
>   }
>   return $res;
>
> }

Thanks, I was looking for something like this, that's very helpful.
Looking at the output, the principal differences seem to be:

1) The database doesn't have CRLF where the generated output does;
instead it just has LF.  (Diff does not pick up these.)
2) The generated output has this sequence representing an apostrophe:
26 23 33 39 3b all the way through except near the end, where it's
represented as simply 27.  In the database, it's 27 all the way
through.

Now when I look at the generating code:

		local our $table_cases = join("\n\tELS",@table_cases) . ' END IF;';
		local our $get_name = qq~DECLARE
	c refcursor;
	n text;
BEGIN
	$table_cases
	FETCH c INTO n;
	IF n IS NOT NULL THEN
		RETURN n;
	ELSE
		RETURN t || ' ' || id || ' (doesn''t exist)';
	END IF;
END;~;

Those apostrophes inside the qq~~ block are the only ones that come
out as 27, whereas all the ones from join come out as the 26 23 33 39
3b.

Oh.  <smacks forehead>

I had been encoding HTML entities to display in the browser...I
completely forgot about that last step before my builder function
returns each table case...I'll be moving that piece of code to a
better place now...

Thank you so much for your help!

Kev