Re: proposal or just idea for psql - show first N rows from relation backslash statement

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, fabriziomello(at)gmail(dot)com, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal or just idea for psql - show first N rows from relation backslash statement
Date: 2013-02-14 15:52:05
Message-ID: CAHyXU0xMxF-O0J6_xuiK_p5ZfK2kKWjXCG6vktXW_cL5xFN7pg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 14, 2013 at 8:43 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>> My proposal should not replace stored procedures.
>
> Stored procedures, with actual transaction-management capabilities, is a
> completely different topic which isn't usefully involved here.
>
>> The core of my proposal was using autocomplete for one often task.
>
> TABLE already supports tab-completion.

TABLE is fine. My point is that often when discussing extensions to
psql are we really working around lack of stored procedures. Talk of
stored procedures is not off topic, because they could directly
implement proposed $feature in a much more general way. I am very
sanguine about implementation difficulties but please don't shoot the
messenger.

> SELECT top10('foo');

That doesn't work. functions don't allow arbitrary returned columns.
CALL should support this.

Anyways, if we are counting characters,
TA<tab> fo<tab> limit 10; < 17
CA<tab> to<tab>('foo'); < 15 (but different table name could
certainly swing it)

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-02-14 15:55:18 Re: pg_upgrade old cluster delete script
Previous Message Jehan-Guillaume de Rorthais 2013-02-14 15:45:42 Unarchived WALs deleted after crash