Hello
I reduced this patch as just plpgsql (SPI) problem solution.
Correct generic solution needs a discussion about enhancing our libpq
interface - we can take a number of returned rows, but we should to
get number of processed rows too. A users should to parse this number
from completationTag,
On Friday, September 28, 2012 2:28 AM Pavel Stehule wrote:
Hello
I reduced this patch as just plpgsql (SPI) problem solution.
Correct generic solution needs a discussion about enhancing our libpq
interface - we can take a number of returned rows, but we should to get
number of processed
2012/9/28 Amit Kapila amit.kap...@huawei.com:
On Friday, September 28, 2012 2:28 AM Pavel Stehule wrote:
Hello
I reduced this patch as just plpgsql (SPI) problem solution.
Correct generic solution needs a discussion about enhancing our libpq
interface - we can take a number of returned
On Friday, September 21, 2012 1:23 AM Pavel Stehule wrote:
Basic stuff:
- Patch applies OK. but offset difference in line numbers.
- Compiles with errors in contrib [pg_stat_statements, sepgsql] modules
- Regression failed; one test-case in COPY due to incomplete test-case
On 16.08.2012 14:43, Pavel Stehule wrote:
Hello
here is updated patch
[Review of Patch]
Basic stuff:
- Patch applies OK. but offset difference in line numbers.
- Compiles with errors in contrib [pg_stat_statements, sepgsql] modules
- Regression failed; one test-case
Hello
Basic stuff:
- Patch applies OK. but offset difference in line numbers.
- Compiles with errors in contrib [pg_stat_statements, sepgsql] modules
- Regression failed; one test-case in COPY due to incomplete test-case
attached patch. – same as reported by Heikki
fixed
