From: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: add line number as prompt option to psql |
Date: | 2014-08-21 02:43:48 |
Message-ID: | CAD21AoD_VhOQZFeiYhgMLNEN0akqkoN9JRVUTgdCkfmT8X14bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 20, 2014 at 9:00 PM, Jeevan Chalke
<jeevan(dot)chalke(at)enterprisedb(dot)com> wrote:
> Hi,
>
> I have reviewed this:
>
> I have initialize cur_lineno to UINTMAX - 2. And then observed following
> behaviour to check wrap-around.
>
> postgres=# \set PROMPT1 '%/[%l]%R%# '
> postgres[18446744073709551613]=# \set PROMPT2 '%/[%l]%R%# '
> postgres[18446744073709551613]=# select
> postgres[18446744073709551614]-# a
> postgres[18446744073709551615]-# ,
> postgres[0]-# b
> postgres[1]-# from
> postgres[2]-# dual;
>
> It is wrapping to 0, where as line number always start with 1. Any issues?
>
> I would like to ignore this as UINTMAX lines are too much for a input
> buffer to hold. It is almost NIL chances to hit this.
>
>
> However, I think you need to use UINT64_FORMAT while printing uint64
> number. Currently it is %u which wrap-around at UINT_MAX.
> See how pset.lineno is displayed.
>
> Apart from this, I didn't see any issues in my testing.
>
> Patch applies cleanly. make/make install/initdb/make check all are well.
>
Thank you for reviewing the patch!
Attached patch is latest version patch.
I modified the output format of cur_lineno.
Regards,
-------
Sawada Masahiko
Attachment | Content-Type | Size |
---|---|---|
psql-line-number_v7.patch | application/octet-stream | 3.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-08-21 03:00:43 | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
Previous Message | Bruce Momjian | 2014-08-21 00:19:25 | Re: PQgetssl() and alternative SSL implementations |