[DOCS] bug in 8.0 manual, section 37.6, PL/Perl Triggers

2005-01-20 Thread Rainer Brandt
Hi,

All places that mention the trigger event info hash pointer $_TD
end with the "->" characters.  The hash keys are omitted.
That is certainly not what you wanted.
(Also, the code examples will not compile under Perl.  (I didn't
try, but can see that they won't.))

Probably due to the character '>' and some Docbook -> HTML conversion?

Greetings, Rainer

P.S.: Great to see this new version of PL/Perl.
-- 
--
Rainer J. H. Brandtemail: [EMAIL PROTECTED]
Brandt & Brandt Computer GmbH  web:www.bb-c.de
Kamberg 111phone:  +49 2448 919126
D 53940 Hellenthal mobile: +49 172 9593205

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [DOCS] [BUGS] BUG #1414: DOC - pl/Perl hash tags missing

2005-01-20 Thread Tom Lane
"Mike Blackwell" <[EMAIL PROTECTED]> 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

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

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [DOCS] [BUGS] BUG #1414: DOC - pl/Perl hash tags missing

2005-01-20 Thread Magnus Hagander
>> 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

---(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


Re: [DOCS] [BUGS] BUG #1414: DOC - pl/Perl hash tags missing

2005-01-20 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 3: 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: [pgsql-www] [DOCS] [BUGS] BUG #1414: DOC - pl/Perl hash tags missing

2005-01-20 Thread Magnus Hagander
>> 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:[EMAIL PROTECTED]:/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

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [DOCS] [BUGS] BUG #1414: DOC - pl/Perl hash tags missing

2005-01-20 Thread Alvaro Herrera
On Thu, Jan 20, 2005 at 04:23:16PM -0500, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> 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 (<[EMAIL PROTECTED]>)
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".

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

   http://archives.postgresql.org


Re: [pgsql-www] [DOCS] [BUGS] BUG #1414: DOC - pl/Perl hash tags

2005-01-20 Thread Alexey Borzov
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.

---(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