Re: Entities created in one query not available in another in extended protocol

I just understood the same thing Tom wrote, yes, Npgsql (currently) sends
Parse for the second command before sending Execute for the first one. I
will look into that implementation decision. It might be worth looking into
Simon's comment though, I'll report if I still see the same problematic
behavior after reordering the messages (assuming we do reorder).

Thanks for your inputs...

On Thu, Jun 11, 2015 at 5:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On 11 June 2015 at 11:20, Shay Rojansky <roji(at)roji(dot)org> wrote:
> >> It appears that when we send two messages in an extended protocol (so
> two
> >> Parse/Bind/Execute followed by a single Sync), where the first one
> creates
> >> some entity (function, table), and the second one can't query that
> entity
> >> (not found). This isn't terribly important but does seem a bit odd, I
> >> wanted to make sure you're aware of this.
>
> > Sounds somewhat unlikely, but thank you for the report. Can we see a test
> > case?
>
> > Most commonly in such cases the first request failed and error messages
> > weren't checked before running second message.
>
> I'm wondering if it was really more like
> Parse/Parse/Bind/Bind/Execute/Execute/Sync, in which case the described
> behavior wouldn't be too surprising at all.
>
> I do note that if a transaction is implicitly started to execute these
> messages, it's not closed until Sync. But that should only affect the
> visibility of the results to other sessions, not to the current one.
> There's definitely a CommandCounterIncrement in exec_execute_message ...
>
> regards, tom lane
>