On Wed, Aug 20, 2014 at 9:00 PM, Jeevan Chalke
<jeevan.cha...@enterprisedb.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.


Sawada Masahiko

Attachment: psql-line-number_v7.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to