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

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ...
Date: 2003-03-09 03:03:45
Message-ID: 3E6AAF11.4090402@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2003-03-09 03:10:42 Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ...
Previous Message Tom Lane 2003-03-09 02:56:22 Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ...