BUG #1414: DOC - pl/Perl hash tags missing

"Mike Blackwell" <maiku41@anet.com> writes:

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.

Yeah, I see the same; but it's not in the devel docs. Compare
http://www.postgresql.org/docs/8.0/static/plperl.html
http://developer.postgresql.org/docs/postgres/plperl.html
and look for instance at the empcomp() function about halfway down
the page:
return $emp-> + $emp->;
vs
return $emp->{basesalary} + $emp->{bonus};

Any theories what's wrong here?

regards, tom lane

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.

Yeah, I see the same; but it's not in the devel docs. Compare
http://www.postgresql.org/docs/8.0/static/plperl.html
http://developer.postgresql.org/docs/postgres/plperl.html
and look for instance at the empcomp() function about halfway down
the page:
return $emp-> + $emp->;
vs
return $emp->{basesalary} + $emp->{bonus};

Any theories what's wrong here?

Going out on a line a bit here - and someone who've worked with teh
system probably knows for sure but... It looks like {} is used as the
template placeholder in the templating system on the website.

It would seem to me that the fix would be as simple as to set
$removeUnknownVariables to false when parsing the docs template, but I'm
far from sure at that. And I have no way to test it. And it might break
something else. End of disclaimers.

Anyway. If it helped one of the web guys in the right direction
(assuming it was right), then there was some point to this post ;-)

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

Going out on a line a bit here - and someone who've worked with teh
system probably knows for sure but... It looks like {} is used as the
template placeholder in the templating system on the website.

It would seem to me that the fix would be as simple as to set
$removeUnknownVariables to false when parsing the docs template, but I'm
far from sure at that. And I have no way to test it. And it might break
something else. End of disclaimers.

If the docs template is applying any substitution whatsoever to the
documentation HTML files, it's broken. I don't think the above fix
is appropriate --- what if the docs contain {foo} where foo does match
some variable known to the substituter?

regards, tom lane

Hi,

Magnus Hagander 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.

Yeah, I see the same; but it's not in the devel docs. Compare
http://www.postgresql.org/docs/8.0/static/plperl.html
http://developer.postgresql.org/docs/postgres/plperl.html
and look for instance at the empcomp() function about halfway down
the page:
return $emp-> + $emp->;
vs
return $emp->{basesalary} + $emp->{bonus};

Any theories what's wrong here?

Going out on a line a bit here - and someone who've worked with teh
system probably knows for sure but... It looks like {} is used as the
template placeholder in the templating system on the website.

Yes, that's exactly the case...

It would seem to me that the fix would be as simple as to set
$removeUnknownVariables to false when parsing the docs template, but I'm
far from sure at that. And I have no way to test it. And it might break
something else. End of disclaimers.

The clean solution would be to use
$tpl->setOption('preserve_data', true);

In this case there will be no problems even if a known placeholder appears in
the docs.

Sorry, cannot fix it myself right now, don't want to checkout the website code
as there is a sh*tload of PDF docs in there.

Going out on a line a bit here - and someone who've worked with teh
system probably knows for sure but... It looks like {} is used as the
template placeholder in the templating system on the website.

Yes, that's exactly the case...

Ahh, I'm not totally PHP illiterate,...

It would seem to me that the fix would be as simple as to set
$removeUnknownVariables to false when parsing the docs

template, but I'm

far from sure at that. And I have no way to test it. And it

might break

something else. End of disclaimers.

The clean solution would be to use
$tpl->setOption('preserve_data', true);

In this case there will be no problems even if a known
placeholder appears in
the docs.

... though as expected, I don't know the template system ;-)

Sorry, cannot fix it myself right now, don't want to checkout
the website code
as there is a sh*tload of PDF docs in there.

Um. There should be no problem checking out just a subdir, no? Just do
cvs -d :pserver:anonymous@gborg.postgresql.org:/usr/local/cvsroot/pgweb
co portal/system

or whatever dir it is you need (or a single file should work too).
You don't want to use anoncvs if you're going to commit, of course. I
don't know which format CVSROOTs are used on gborg for authenticated
access.

//Magnus

On Thu, Jan 20, 2005 at 04:23:16PM -0500, Tom Lane wrote:

"Magnus Hagander" <mha@sollentuna.net> writes:

Going out on a line a bit here - and someone who've worked with teh
system probably knows for sure but... It looks like {} is used as the
template placeholder in the templating system on the website.

It would seem to me that the fix would be as simple as to set
$removeUnknownVariables to false when parsing the docs template, but I'm
far from sure at that. And I have no way to test it. And it might break
something else. End of disclaimers.

If the docs template is applying any substitution whatsoever to the
documentation HTML files, it's broken. I don't think the above fix
is appropriate --- what if the docs contain {foo} where foo does match
some variable known to the substituter?

Probably the solution is to use some sort of template escaping, like
{literal} in PHP's smarty. Not sure what the site is using.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Al principio era UNIX, y UNIX habl� y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".

-----Original Message-----
From: pgsql-www-owner@postgresql.org
[mailto:pgsql-www-owner@postgresql.org] On Behalf Of Alexey Borzov
Sent: 20 January 2005 21:29
To: Magnus Hagander
Cc: Tom Lane; Mike Blackwell; pgsql-docs@postgresql.org;
pgsql-www@postgresql.org
Subject: Re: [pgsql-www] [DOCS] [BUGS] BUG #1414: DOC -
pl/Perl hash tags

The clean solution would be to use
$tpl->setOption('preserve_data', true);

In this case there will be no problems even if a known
placeholder appears in
the docs.

Thanks Alexey - fixed in CVS, next docs regen is in about 20 hours.

/D

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

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

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

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