From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add support for logging the current role |
Date: | 2011-02-11 15:54:50 |
Message-ID: | AANLkTi=-+wdguWpTE_vLDWoW39UmR-y3sLj5mhZb=cVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 11, 2011 at 10:52 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
>> > Should we abbreviate something there? max_pred_locks_per_tran,
>> > maybe?
>>
>> If we're going to abbreviate transaction, I'd vote for txn over tran,
>> but I think Stephen's point that this is already a lost cause may have
>> some validity. Not sure what other people think.
>
> There's lots of other GUCs with "transaction" spelled out in them.. :/
>
> Another option, which I don't like, would be to use 'default' by
> 'default', and build the list on the fly every time if that's what it
> is.. That would give no insight into what the list of fields is for
> someone though, they'd have to go back to the documentation to figure
> it out, and that sucks..
Yeah. The root cause of this problem is that the way psql handles
tabular output with a few very wide rows stinks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2011-02-11 15:55:45 | Re: pl/python invalidate functions with composite arguments |
Previous Message | Robert Haas | 2011-02-11 15:53:42 | Re: pl/python invalidate functions with composite arguments |