On 1/10/18 13:53, Vladimir Sitnikov wrote:
>> committed
>
> I'm afraid it causes regressions for pgjdbc.
> Here's CI log: https://travis-ci.org/pgjdbc/pgjdbc/jobs/327327402
>
> The errors are:
> testMetaData[typeName = REF_CURSOR, cursorType =
> 2,012](org.postgresql.test.jdbc2.RefCursorTest) Ti
> committed
I'm afraid it causes regressions for pgjdbc.
Here's CI log: https://travis-ci.org/pgjdbc/pgjdbc/jobs/327327402
The errors are:
testMetaData[typeName = REF_CURSOR, cursorType =
2,012](org.postgresql.test.jdbc2.RefCursorTest) Time elapsed: 0.032 sec
<<< ERROR! org.postgresql.util.PSQL
On 1/8/18 20:28, Peter Eisentraut wrote:
> On 1/8/18 15:27, Andrew Dunstan wrote:
>> This seems like a good idea, and the code change is tiny and clean. I
>> don't know of any third party PLs or other libraries might be pinning
>> the portals already on their own. How would they be affected if they
On 1/8/18 15:27, Andrew Dunstan wrote:
> This seems like a good idea, and the code change is tiny and clean. I
> don't know of any third party PLs or other libraries might be pinning
> the portals already on their own. How would they be affected if they did?
They would get an error if they tried t
On 12/15/2017 03:36 PM, Peter Eisentraut wrote:
> On 12/12/17 10:34, Peter Eisentraut wrote:
>> But I also wonder whether we shouldn't automatically pin/unpin portals
>> in SPI_cursor_open() and SPI_cursor_close(). This makes sense if you
>> consider "pinned" to mean "internally generated". I d
On 12/12/17 10:34, Peter Eisentraut wrote:
> But I also wonder whether we shouldn't automatically pin/unpin portals
> in SPI_cursor_open() and SPI_cursor_close(). This makes sense if you
> consider "pinned" to mean "internally generated". I don't think there
> is a scenario in which user code sho
