Thread: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ...

CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    tgl@postgresql.org    03/03/08 21:19:14

Modified files:
    contrib/tablefunc: tablefunc.c
    src/backend/executor: execQual.c nodeMaterial.c
    src/backend/utils/sort: tuplestore.c
    src/include/nodes: execnodes.h
    src/include/utils: tuplestore.h
    src/pl/plpgsql/src: pl_exec.c

Log message:
    Revise tuplestore and nodeMaterial so that we don't have to read the
    entire contents of the subplan into the tuplestore before we can return
    any tuples.  Instead, the tuplestore holds what we've already read, and
    we fetch additional rows from the subplan as needed.  Random access to
    the previously-read rows works with the tuplestore, and doesn't affect
    the state of the partially-read subplan.  This is a step towards fixing
    the problems with cursors over complex queries --- we don't want to
    stick in Materialize nodes if they'll prevent quick startup for a cursor.

Tom Lane wrote:
> Log message:
>     Revise tuplestore and nodeMaterial so that we don't have to read the
>     entire contents of the subplan into the tuplestore before we can return
>     any tuples.  Instead, the tuplestore holds what we've already read, and
>     we fetch additional rows from the subplan as needed.  Random access to
>     the previously-read rows works with the tuplestore, and doesn't affect
>     the state of the partially-read subplan.  This is a step towards fixing
>     the problems with cursors over complex queries --- we don't want to
>     stick in Materialize nodes if they'll prevent quick startup for a cursor.
>

So if I understand this correctly, tuplestore_donestoring() is not used
anymore (and doen't even exist)? Anything else changed in tuplestore
behavior? I have to update PL/R also for this.

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:
> So if I understand this correctly, tuplestore_donestoring() is not used
> anymore (and doen't even exist)? Anything else changed in tuplestore
> behavior? I have to update PL/R also for this.

Yeah, I got rid of it.  I was considering leaving it present as a no-op
routine, but felt there weren't enough users to justify any backwards-
compatibility concern.  But I'm open to argument if you think different.

The principal change in behavior is that you can start fetching tuples
from the tuplestore before you've stored 'em all; there are separate
read and write pointers.  Dunno if this is of any value to you, but
it's there if you can find a use.

            regards, tom lane

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>
>>So if I understand this correctly, tuplestore_donestoring() is not used
>>anymore (and doen't even exist)? Anything else changed in tuplestore
>>behavior? I have to update PL/R also for this.
>
>
> Yeah, I got rid of it.  I was considering leaving it present as a no-op
> routine, but felt there weren't enough users to justify any backwards-
> compatibility concern.  But I'm open to argument if you think different.

I don't really want to argue for it, but is there a way I can deduce the
non-availability of the function without resorting to creating my own
configure script? I was thinking about checking CATALOG_VERSION_NO, but
I see you didn't need to roll that. In any case, would it work to do
something like:

#if (CATALOG_VERSION_NO < 200303081)
#define Tuplestore_Donestoring(tupstore) \
                        tuplestore_donestoring(tupstore)
#else
#define Tuplestore_Donestoring(tupstore)
#endif

> The principal change in behavior is that you can start fetching tuples
> from the tuplestore before you've stored 'em all; there are separate
> read and write pointers.  Dunno if this is of any value to you, but
> it's there if you can find a use.

It sounds interesting -- I'll have to think about that some more.

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:
> I don't really want to argue for it, but is there a way I can deduce the
> non-availability of the function without resorting to creating my own
> configure script? I was thinking about checking CATALOG_VERSION_NO, but
> I see you didn't need to roll that. In any case, would it work to do
> something like:

Will you be satisfied with
    #define tuplestore_donestoring(tupstore)  ((void) 0)
?  That would provide source-level, but not link-level, compatibility.

            regards, tom lane

Tom Lane wrote:
> Will you be satisfied with
>     #define tuplestore_donestoring(tupstore)  ((void) 0)
> ?  That would provide source-level, but not link-level, compatibility.
>

OK, that seems to work -- I did this:

#if (CATALOG_VERSION_NO > 200303080)
#define tuplestore_donestoring(tupstore)  ((void) 0)
#endif

and modified CATALOG_VERSION_NO to 200303081 locally. I don't think
there are many (if any) people trying to use PL/R with cvs tip. After
the next catalog version change, everything should be transparent.

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> Will you be satisfied with
>> #define tuplestore_donestoring(tupstore)  ((void) 0)
>> ?  That would provide source-level, but not link-level, compatibility.

> OK, that seems to work -- I did this:

> #if (CATALOG_VERSION_NO > 200303080)
> #define tuplestore_donestoring(tupstore)  ((void) 0)
> #endif

Actually, I meant I was willing to throw that into tuplestore.h ---
and have now done so.  So you shouldn't need the CATALOG_VERSION_NO
hack.

            regards, tom lane

Tom Lane wrote:
> Actually, I meant I was willing to throw that into tuplestore.h ---
> and have now done so.  So you shouldn't need the CATALOG_VERSION_NO
> hack.
>

Oh -- great! Thanks,

Joe