Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
Looking at the end of the discussion about \cset, it seems what
y
Tom Lane wrote:
> Keep in mind that a large part of the reason why the \cset patch got
> bounced was exactly that its detection of \; was impossibly ugly
> and broken. Don't expect another patch using the same logic to
> get looked on more favorably.
Looking at the end of the discussion
Hello Tom,
Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
Although I do not claim that my implementation was ve
"Daniel Verite" writes:
> Fabien COELHO wrote:
>> I added some stuff to extract embedded "\;" for pgbench "\cset", which has
>> been removed though, but it is easy to add back a detection of "\;", and
>> also to detect select. If the position of the last select is known, the
>> cursor can
Fabien COELHO wrote:
> I added some stuff to extract embedded "\;" for pgbench "\cset", which has
> been removed though, but it is easy to add back a detection of "\;", and
> also to detect select. If the position of the last select is known, the
> cursor can be declared in the right pl
Bonjour Daniel,
When FETCH_COUNT is set, queries combined in a single request don't work
as expected:
\set FETCH_COUNT 10
select pg_sleep(2) \; select 1;
No result is displayed, the pg_sleep(2) is not run, and no error
is shown. That's disconcerting.
Indeed.
Does anyone have thoughts abo
Hi,
When FETCH_COUNT is set, queries combined in a single request don't work
as expected:
\set FETCH_COUNT 10
select pg_sleep(2) \; select 1;
No result is displayed, the pg_sleep(2) is not run, and no error
is shown. That's disconcerting.
The sequence that is sent under the hood is:
#1 BEG
