2012/9/28 Amit Kapila :
>> 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
> 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 pro
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 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 te
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
fi
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-ca
On 16.08.2012 14:43, Pavel Stehule wrote:
Hello
here is updated patch
The patch seems to be truncated, it ends with:
*** a/src/test/regress/input/copy.source
--- b/src/test/regress/input/copy.source
***
*** 106,108 this is just a line full of junk that would error out
if par
Hello
here is updated patch
postgres=# copy omega to '/tmp/xxx';
COPY 60
postgres=# do $$ declare r int;
begin
copy omega from '/tmp/xxx'; get diagnostics r = row_count; raise
notice '>>> %', r;
end;
$$ language plpgsql;
NOTICE: >>> 60
DO
Regards
Pavel
2012/8/16 Bruce Momjian :
>
> What ev
Hello
I can reassign it again
Regards
Pavel
2012/8/16 Bruce Momjian :
>
> What ever happened to this patch? I don't see it on any of the
> commit-fests, though someone was asked for it to be added:
>
> http://archives.postgresql.org/pgsql-hackers/2011-10/msg00381.php
>
> --
What ever happened to this patch? I don't see it on any of the
commit-fests, though someone was asked for it to be added:
http://archives.postgresql.org/pgsql-hackers/2011-10/msg00381.php
---
On Tue, Oct 4, 2011 a
Pavel Stehule wrote:
> There is not possible to get a number of processed rows when COPY
> is evaluated via SPI. Client can use a tag, but SPI doesn't use a
> tag.
>
> I propose a small change a ProcessUtility to return a processed
> rows.
Please add this to the open CommitFest:
https://com
Hello
There is not possible to get a number of processed rows when COPY is
evaluated via SPI. Client can use a tag, but SPI doesn't use a tag.
I propose a small change a ProcessUtility to return a processed rows.
Note: I found a small inconsistency between SPI and Utility interface.
SPI still us
12 matches
Mail list logo
