Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ...
От | Joe Conway |
---|---|
Тема | Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ... |
Дата | |
Msg-id | 3E6AAF11.4090402@joeconway.com обсуждение исходный текст |
Ответ на | Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql-server/ ontrib/tablefunc/tablefunc.c rc/ ...
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: