Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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) \
#define Tuplestore_Donestoring(tupstore)

> 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.



In response to


pgsql-committers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group