> On 29 Jul 2021, at 16:45, Daniel Verite wrote:
> Trying the v7a patch, here are a few comments:
This thread has stalled with no update or response to the above, and the patch
errors out on make check for the plpgsql suite. I'm marking this Returned with
Feedback, please resubmit an updated pa
Hi,
Trying the v7a patch, here are a few comments:
* SIGSEGV with ON HOLD cursors.
Reproducer:
declare c cursor with hold for select oid,relname
from pg_class order by 1 limit 10;
select * from rows_in('c') as x(f1 oid,f2 name);
consumes a bit of time, then crashes and generates a 13 GB
Hi Massimo,
Happy to help. And actually, end user (i.e., developer) feedback on the
feature’s usefulness is probably one of the more important contributions.
d.
> On 10 Feb 2021, at 08:57, Massimo Fidanza wrote:
>
> Hi John,
>
> I never build postgresql from source, so I must get some inform
Hi John,
I never build postgresql from source, so I must get some information on how
to apply your patch and do some test. I can't review your code because I
know nothing about Postgresql internals and just basic C. I am mainly a
PL/SQL programmer, with experience with PHP, Python and Javascript.
Hi Massimo,
Thanks for the interest, and my apologies for the late reply.
I’m not particularly abandoning it, but I don’t have particular reason to make
further changes at the moment. Far as I’m concerned it works, and the main
question is whether it is acceptable and useful.
I’d be happy if y
This is an interesting feature, but it seems that the author has abandoned
development, what happens now? Will this be postponed from commitfest to
commitfest and never be taken over by anyone?
Massimo.
Il giorno ven 6 mar 2020 alle ore 22:36 Dent John ha
scritto:
> > On 22 Feb 2020, at 10:38,
> On 22 Feb 2020, at 10:38, Dent John wrote:
>
>> On 18 Feb 2020, at 03:03, Thomas Munro wrote:
>>
>> From the trivialities department, I see a bunch of warnings about
>> local declaration placement (we're still using C90 rules for those by
>> project policy):
>>
>> […]
>
> […]
My bad. I mis
> On 18 Feb 2020, at 03:03, Thomas Munro wrote:
>
> From the trivialities department, I see a bunch of warnings about
> local declaration placement (we're still using C90 rules for those by
> project policy):
>
> refcursor.c:138:3: error: ISO C90 forbids mixed declarations and code
> [-Werror=de
On Sat, Jan 25, 2020 at 11:59 PM Dent John wrote:
> Attached patch addresses these points, so should now apply cleanly agains dev.
>From the trivialities department, I see a bunch of warnings about
local declaration placement (we're still using C90 rules for those by
project policy):
refcursor.c
> On 19 Jan 2020, at 22:30, Dent John wrote:
>
> I have not yet made steps towards documentation, nor yet rebased, so the
> Makefile chunk will probably still fail.
Attached patch addresses these points, so should now apply cleanly agains dev.
I also changed the OID assigned to ROWS_IN and its
> On 11 Jan 2020, at 12:04, Dent John wrote:
>
>> On 10 Jan 2020, at 15:45, Daniel Verite wrote:
>>
>> postgres=# select unnest('c'::refcursor);
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the reque
> On 14 Jan 2020, at 14:53, Daniel Verite wrote:
>
> What is the expected result anyway? A single column with a "record"
> type? FWIW I notice that with plpgsql, this is not allowed to happen:
Hmm. How interesting.
I had not really investigated what happens in the case of a function returning
Dent John wrote:
> It’s crashing when it’s checking that the returned tuple matches the
> declared return type in rsinfo->setDesc. Seems rsinfo->setDesc gets
> overwritten. So I think I have a memory management problem.
What is the expected result anyway? A single column with a "record"
t
> On 10 Jan 2020, at 15:45, Daniel Verite wrote:
>
> At a quick glance, I don't see it called in the select-list in any
> of the regression tests. […]
Yep. I didn’t test it because I figured it wasn’t particularly useful in that
context. I’ll add some tests for that too once I get to the root
Dent John wrote:
> Yes. That’s at least true if unnest(x) is used in the FROM. If it’s used in
> the SELECT, actually it can get the performance benefit right away
At a quick glance, I don't see it called in the select-list in any
of the regression tests. When trying it, it appears to cr
> On 9 Jan 2020, at 17:43, Daniel Verite wrote:
>
> […]
> (using plain text instead of HTML messages might help with that).
Thanks. I’ll do that next time.
> […]
> * unnest-refcursor-v3.patch needs a slight rebase because this chunk
> in the Makefile fails
> - regexp.o regproc.o ri_triggers
Dent John wrote:
> I’ve made a revision of this patch.
Some comments:
* the commitfest app did not extract up the patch from the mail,
possibly because it's buried in the MIME structure of the mail
(using plain text instead of HTML messages might help with that).
The patch has no status
Hi folks,I’ve made a revision of this patch. The significant change is to access the Portal using Portal APIs rather than through SPI. It seems the persisted state necessary to survive being used to retrieve a row at a time inside an SRF just isn’t a good fit for SPI. It turned out there was upstre
Hi John,
Thanks for pushing this, for me it looks like promising start! I need a bit
more time to go through the code (and I'm not an expert in Postgres
internals in any way) but I really appreciate you doing this.
Roman
Hi folks,Prompted originally by a post by Roman Pekar [1], I wanted to share a revised version of a patch that allows REFCURSOR results to be consumed as data in a regular SQL query as well as my thoughts on how to improve the area as a whole.In order to be clear about the purpose and how I see it
20 matches
Mail list logo
