Обсуждение: pgsql/src/backend/utils/cache (fcache.c)

  Date: Tuesday, August  8, 2000 @ 11:42:28
Author: tgl

Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/cache
     from hub.org:/home/projects/pgsql/tmp/cvs-serv31974/src/backend/utils/cache

Modified Files:
    fcache.c

-----------------------------  Log Message  -----------------------------

Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist'
from Param nodes, per discussion a few days ago on pghackers.  Add new
expression node type FieldSelect that implements the functionality where
it's actually needed.  Clean up some other unused fields in Func nodes
as well.
NOTE: initdb forced due to change in stored expression trees for rules.

> -----Original Message-----
> From: Tom Lane
>
> Modified Files:
>     fcache.c
>
> -----------------------------  Log Message  -----------------------------
>
> Remove 'func_tlist' from Func expression nodes, likewise 'param_tlist'
> from Param nodes, per discussion a few days ago on pghackers.  Add new
> expression node type FieldSelect that implements the functionality where
> it's actually needed.  Clean up some other unused fields in Func nodes
> as well.
> NOTE: initdb forced due to change in stored expression trees for rules.
>

I see the following Assert in GetDynamicFuncArgType().

        /* TEST: I bet this routine is unnecessary ... */
        Assert(arg->vartype == tup->t_data->t_oid);

Seems the Assert() fails in misc regression test at
    SELECT p.name, p.hobbies.name FROM person* p;.
etc ...(pararell regression test invokes postmaster without -A
option unfortunately).

The definition of hobbies() is as follows.

 CREATE FUNCTION hobbies(person)
    RETURNS setof hobbies_r
    AS 'select * from hobbies_r where person = $1.name'
    LANGUAGE 'sql';

When a subclass of person is passed to the hobbies() function
the Assert() seems to fail.

In additon this example gives me some other questions.
1) Could PL/pgSQL functions handle input tuple parameter
    properly when the class of the tuple has subclasses ?
2) Could functions return multiple subclasses when returning
    (setof) tuple(s) ?
    If so,could FieldSelect Nodes handle such cases properly ?

Regards.

Hiroshi Inoue

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> I see the following Assert in GetDynamicFuncArgType().

>         /* TEST: I bet this routine is unnecessary ... */
>         Assert(arg->vartype == tup->t_data->t_oid);

> Seems the Assert() fails in misc regression test at
>     SELECT p.name, p.hobbies.name FROM person* p;.

Really?  It does not fail for me (else I'd certainly not have
committed the patch this way).

That assert is groundwork for some additional changes I haven't
yet made, leading up to being able to call SQL functions via
fmgr.  So if it fails I want to know about it!  Do you have any
idea what might be different between your test and mine?

            regards, tom lane

I said:
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> Seems the Assert() fails in misc regression test at
>> SELECT p.name, p.hobbies.name FROM person* p;.

> Really?  It does not fail for me (else I'd certainly not have
> committed the patch this way).

Ah ... it seems that someone has changed the behavior of assert checking
to default to OFF, with no public notice or discussion.  I think this is
an extremely ill-considered change --- I will restore the old default
behavior forthwith.

After that I can start worrying about this Assert failure :-(.  Thanks
for the heads-up.

            regards, tom lane

On Fri, 11 Aug 2000, Tom Lane wrote:

> I said:
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> Seems the Assert() fails in misc regression test at
> >> SELECT p.name, p.hobbies.name FROM person* p;.
>
> > Really?  It does not fail for me (else I'd certainly not have
> > committed the patch this way).
>
> Ah ... it seems that someone has changed the behavior of assert checking
> to default to OFF, with no public notice or discussion.  I think this is
> an extremely ill-considered change --- I will restore the old default
> behavior forthwith.

Huh?  I thought Assert checking was always off by default until
--enable-cassert was set at configure time ... ?  its been that way for as
long as I can remember ... or are we talking abuot a 'post
--enable-cassert configured' compile, using our config file?

The Hermit Hacker <scrappy@hub.org> writes:
>> Ah ... it seems that someone has changed the behavior of assert checking
>> to default to OFF, with no public notice or discussion.  I think this is
>> an extremely ill-considered change --- I will restore the old default
>> behavior forthwith.

> Huh?  I thought Assert checking was always off by default until
> --enable-cassert was set at configure time ... ?

Right.  But Peter added a run-time "debug_assertions" SET variable,
which is cool except he made it default to OFF.  So --enable-cassert
wasn't enough to get assert checking anymore :-(.  I changed the SET
variable to default to ON.

            regards, tom lane

On Fri, 11 Aug 2000, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> >> Ah ... it seems that someone has changed the behavior of assert checking
> >> to default to OFF, with no public notice or discussion.  I think this is
> >> an extremely ill-considered change --- I will restore the old default
> >> behavior forthwith.
>
> > Huh?  I thought Assert checking was always off by default until
> > --enable-cassert was set at configure time ... ?
>
> Right.  But Peter added a run-time "debug_assertions" SET variable,
> which is cool except he made it default to OFF.  So --enable-cassert
> wasn't enough to get assert checking anymore :-(.  I changed the SET
> variable to default to ON.

that's what I was starting to think about as I asked, but figured it
wouldn't hurt to clarify :)