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
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
Import Notes
Reply to msg id not found: 17147.1047180926@sss.pgh.pa.us
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