Re: [HACKERS] Is this a bug? or am I doing some thing wrong?

Terry Mackintosh wrote:

> [...]
> shell_connection->                 o.accno = c.accno and
> shell_connection->                 o.stockno = s.stockno;
> ERROR:  DefineQueryRewrite: rule plan string too big.
> shell_connection=>
>
> Is this a bug? or am I doing some thing wrong?
> And if it is a bug, is it fixed in 6.4.1?

    It's  not a real bug, it's a side effect from the fact that a
    tuple cannot span multiple disk blocks.

>
> What's a 'rule plan string'? the part I typed? if so, how long can it be?
> I also tried typing it all as one (wraped) line, but same thing.

    First it's wrong. The system stores a  string  representation
    of  the  rules  querytree in pg_rewrite (not the rules plan).
    Anything the rule system deals  with  are  querytrees.  Those
    ones  coming  from  the parser for the actual query and those
    ones generated for the rule  actions  and  qualifications.  A
    querytree consists of cascaded node structures in memory. The
    function nodeToString() builds a string which  is  stored  in
    pg_rewrite  and  stringToNode()  is  used  to  rebuild the in
    memory structures from that.

    These  strings  are  very  explanative  and  thus  very  long
    compared against the query they represent. They must fit into
    one text type attribute and from the  limitation  above,  the
    resulting  pg_rewrite tuple must fit into one (8k by default)
    disk block.

    While fixing  the  rule  system  for  v6.4  I  thought  about
    implementing  continuation  rows for rewrite rules. But there
    are at least ideas out how tuples could eventually span  disk
    blocks  in  the  future,  so  I  left  that problem untouched
    waiting for this general solution.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #