On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom wrote:
> Concise output might look like (bikeshed argument: "splat" indicates
> columns "squashed" out):
>
> test=# \d+ foo
> Table "public.foo"
> Column | Type # Storage #
> +-+-+
> a | in
On Mon, Nov 07, 2011 at 11:01:39PM -0500, Josh Kupershmidt wrote:
> On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas wrote:
>
> > I can also see myself turning it on and then going
> > - oh, wait, is that column not there, or did it just disappear because
> > I'm in concise mode?
>
> Yeah, that wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-11-2011 21:42, Josh Kupershmidt wrote:
> On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian wrote:
>> Have you tried \d+ with this psql mode:
>>
>>\pset format wrapped
>>
>> It wraps the data so it fits on the screen --- it is my default in
On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane wrote:
>> As I suggested, many more unexpected failures (e.g. \dnS+) pop up when
>> talking to a 7.3 server. It's not a big deal, but it'd be nice if we
>> could instead error out with a "sorry, we're too lazy to try to
>> support 7.3" on the meta-commands
On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian wrote:
> Have you tried \d+ with this psql mode:
>
> \pset format wrapped
>
> It wraps the data so it fits on the screen --- it is my default in my
> .psqlrc.
I think that's one of the many psql features I haven't experimented
with, thanks for
Josh Kupershmidt writes:
> FWIW, I just played around with 7.4 and 7.3 servers. (I had some bad
> memories of the older tarballs not building, but that must have been
> only on OS X -- I can build at least back to 7.3 on this Ubuntu 11.04
> machine.)
> Most meta-commands worked alright on 7.4, or
Robert Haas wrote:
> On Sun, Nov 6, 2011 at 3:29 PM, Josh Kupershmidt wrote:
> > On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes
> > wrote:
> >>> test=# \d+ foo
> >>> ? ? ? ? ? ? ? ? ? ? ? ? Table "public.foo"
> >>> ?Column | ?Type ? | Storage
> >>> +-+-
> >>> ?a ? ? ?|
[Sorry for not CC'ing the list before, I'm still getting used to the
new Gmail interface]
On Tue, Nov 8, 2011 at 11:05 PM, Josh Kupershmidt wrote:
> On Tue, Nov 8, 2011 at 10:04 PM, Tom Lane wrote:
>> Josh Kupershmidt writes:
>>> We're essentially pretending that we support all server versions
Josh Kupershmidt writes:
> We're essentially pretending that we support all server versions with
> this code, instead of erroring out on some definite old version and
> admitting "sorry, can't do it". ...
> I think we should draw a line somewhere about just how far back psql
> must support,
Says
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas wrote:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
Seriously, parts of psql are starting to become a real mess.
[tangenti
2011/11/8 Alvaro Herrera :
> Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011:
>> Isn't that what pagers like 'less' and 'more' do already? May be we
>> could provide a pager more specific to psql output as a contrib or
>> extension.
>
> Well, now that you mention it, all
Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011:
> Isn't that what pagers like 'less' and 'more' do already? May be we
> could provide a pager more specific to psql output as a contrib or
> extension.
Well, now that you mention it, all pagers I know are line-based. I
2011/11/8 Alvaro Herrera :
> What I've imagined for a long time is psql being able to display each
> row in more than one line; for example something like
>
> \df
>
> Listado de funciones
> Esquema | Nombre | Tipo de dato de salida | Tipo
> Tipos de datos de argum
Excerpts from Robert Haas's message of mar nov 08 01:25:31 -0300 2011:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
What I've imagined for a long time is psql being ab
On Mon, Nov 7, 2011 at 11:01 PM, Josh Kupershmidt wrote:
> What really prompted the proposal was my somewhat antiquated use of
> 80-column terminal windows (so that 2 or 3 fit side-by-side
> comfortably on my screen). A lot of the backslash commands are
> creeping well over that 80-column limit, e
On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas wrote:
> I don't strongly object to this, but I wonder how useful it will
> really be in practice. It strikes me as the sort of advanced psql
> hackery that only a few people will use, and only some of those will
> gain any benefit.
I'm probably just
On Sun, Nov 6, 2011 at 3:29 PM, Josh Kupershmidt wrote:
> On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes
> wrote:
>>> test=# \d+ foo
>>> Table "public.foo"
>>> Column | Type | Storage
>>> +-+-
>>> a | integer | plain
>>> b | inte
On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes wrote:
>> test=# \d+ foo
>> Table "public.foo"
>> Column | Type | Storage
>> +-+-
>> a | integer | plain
>> b | integer | plain
>> Has OIDs: no
>
> Using your example, what if column '
2011/11/5 Josh Kupershmidt :
> I'd like to propose a "concise mode" for psql, which users might turn
> on via a \pset option. Concise mode would affect only the output of
> psql's backslash commands. For output results which have some all-NULL
> columns, as in:
>
> test=# \d+ foo
>
19 matches
Mail list logo
