The following bug has been logged online:

Bug reference: 1414
Logged by: Mike Blackwell
Email address: maiku41@anet.com
PostgreSQL version: 8.0.0
Operating system: N/A
Description: DOC - pl/Perl hash tags missing
Details:

In the pl/Perl section of the 8.0.0 manual, as viewed on the postgresql.org
web site, all perl code hash tags seem to be missing. i.e.

$hashref->

displays as

$hashref->

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Mike Blackwell wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1414
> Logged by: Mike Blackwell
> Email address: maiku41@anet.com
> PostgreSQL version: 8.0.0
> Operating system: N/A
> Description: DOC - pl/Perl hash tags missing
> Details:
>
> In the pl/Perl section of the 8.0.0 manual, as viewed on the postgresql.org
> web site, all perl code hash tags seem to be missing. i.e.

I have fixed this. We now just need someone to rebuild the docs for
8.0. The developers page will show the CVS version where this is fixed.

Thanks for the report.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Mike Blackwell wrote:
>> In the pl/Perl section of the 8.0.0 manual, as viewed on the postgresql.org
>> web site, all perl code hash tags seem to be missing. i.e.

> I have fixed this. We now just need someone to rebuild the docs for
> 8.0. The developers page will show the CVS version where this is fixed.

Didn't you read the rest of the thread? The problem was incorrect
filtering of the docs by the webpage template, not anything wrong with
the SGML.

The > to &gt; changes you made are no doubt good for cleanliness' sake,
but they were not necessary and there is no urgent reason to rebuild
anything.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Mike Blackwell wrote:
> >> In the pl/Perl section of the 8.0.0 manual, as viewed on the postgresql.org
> >> web site, all perl code hash tags seem to be missing. i.e.
>
> > I have fixed this. We now just need someone to rebuild the docs for
> > 8.0. The developers page will show the CVS version where this is fixed.
>
> Didn't you read the rest of the thread? The problem was incorrect
> filtering of the docs by the webpage template, not anything wrong with
> the SGML.
>
> The > to &gt; changes you made are no doubt good for cleanliness' sake,
> but they were not necessary and there is no urgent reason to rebuild
> anything.

OK. Thanks.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

I'm preparing to upgrade our PostgreSQL installation from 7.3.5 to
8.0.0. I downloaded, configured, compiled, and did gmake check and
much to my surprise, 26 of the 96 tests failed.

Examination of regression.diffs shows that 1 of the failures is random
(and it is ignored) but 23 of the 26 errors are:

! psql: could not send startup packet: Broken pipe

Interestingly enough, if I load the source code onto a 1GB ram disk and
configure, compile and check it there, all 96 tests pass.

Hardware is RAID 1 using 2 disks with one additional disk as a hot
spare, dual 2.66 GHz Xeon processors with 2 GB of RAM. Operating
system is OpenBSD 3.6.

I'm a little leary of upgrading my PostgreSQL installation with those
kind of failure rates.

I'd appreciate any insight as to why so many tests would fail when run
on disk and pass when run in ram.

Thanks,

Jeff Ross

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match