Re: [PATCHES] selecting large result sets in psql using

From: <chrisnospam(at)1006(dot)org>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <bruce(at)momjian(dot)us>, <david(at)fetter(dot)org>, <pgsql-hackers(at)postgresql(dot)org>, <peter_e(at)gmx(dot)net>
Subject: Re: [PATCHES] selecting large result sets in psql using
Date: 2006-08-22 21:13:10
Message-ID: 49337.87.6.213.195.1156281190.squirrel@www.endian.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

>> True. They could even put it in .psqlrc if they want. Basically need
>> a way to modify \g. Seems a \set is the way we have always done such
>> modifications in the past. The big question is whether this is
>> somehow different. Personally, I don't think so.
>
> If you want a \set variable, then at least make it do something useful:
> make it an integer var that sets the fetch count, rather than
> hard-wiring the count as is done in Chris' existing patch. Zero (or
> perhaps unset) disables.
>
> regards, tom lane

Hello,

first I must admit that I misunderstood Bruce post. I thought he meant
to tweak \pset (psql command to set formatting). This didn't make
sense to me. Only now I realize everyone is talking about \set
(psql internal variable).

That being said, I'm a bit unsure now what we should do.

As Peter said, it is true that mostly this feature would be
used for scripting where \set and \unset are not as cumbersome
to use as in an interactive session.
Tom's idea to factor in the fetch count as an option is also
very tempting.

To cut the Gordon knot I'm going to suggest we use:

\set CURSOR_FETCH fetch_count

and \g and ; are modified such that when they see
this variable set to fetch_count > 0 and the buffer
is a select they would use the modified fetch/output code.

Does this sound reasonable to everyone?

Bye :)
Chris.

--
Chris Mair
http://www.1006.org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2006-08-22 21:22:11 Re: BugTracker (Was: Re: 8.2 features status)
Previous Message Joshua D. Drake 2006-08-22 21:04:05 Re: Tricky bugs in concurrent index build

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-08-22 22:33:35 Re: [PATCHES] selecting large result sets in psql using
Previous Message John Gray 2006-08-22 20:24:32 Re: [GENERAL] pgxml & xpath_table