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. Regards, ------- Sawada Masahiko
psql-line-number_v7.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers