Re: add line number as prompt option to psql

On Fri, Jun 20, 2014 at 7:17 PM, Jeevan Chalke
<jeevan(dot)chalke(at)enterprisedb(dot)com> wrote:
> Hi Sawada Masahiko,
>
> I liked this feature. So I have reviewed it.
>
> Changes are straight forward and looks perfect.
> No issues found with make/make install/initdb/regression.
>
> However I would suggest removing un-necessary braces at if, as we have only
> one statement into it.
>
> if (++cur_line >= INT_MAX)
> {
> cur_line = 1;
> }
>
> Also following looks wrong:
>
> postgres[1]=# select
> postgres[2]-# *
> postgres[3]-# from
> postgres[4]-# tab;
> a
> ---
> (0 rows)
>
> postgres[1]=# select
> *
> from
> tab
> postgres[2]-# where t > 10;
> ERROR: column "t" does not exist
> LINE 5: where t > 10;
> ^
>
> Line number in ERROR is 5 which is correct.
> But line number in psql prompt is wrong.
>
> To get first 4 lines I have simply used up arrow followed by an enter for
> which I was expecting 5 in psql prompt.
> But NO it was 2 which is certainly wrong.
>
> Need to handle above carefully.
>
> Thanks
>
>
> On Thu, Jun 12, 2014 at 10:46 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
> wrote:
>>
>> Hi all,
>>
>> The attached IWP patch is one prompt option for psql, which shows
>> current line number.
>> If the user made syntax error with too long SQL then psql outputs
>> message as following.
>>
>> ERROR: syntax error at or near "a"
>> LINE 250: hoge
>> ^
>> psql teaches me where syntax error is occurred, but it is not kind
>> when SQL is too long.
>> We can use write SQL with ¥e(editor) command(e.g., emacs) , and we can
>> know line number.
>> but it would make terminal log dirty . It will make analyzing of log
>> difficult after error is occurred.
>> (I think that we usually use copy & paste)
>>
>> After attached this patch, we will be able to use %l option as prompting
>> option.
>>
>> e.g.,
>> $ cat ~/.psqlrc
>> \set PROMPT2 '%/[%l]%R%# '
>> \set PROMPT1 '%/[%l]%R%# '
>> $ psql -d postgres
>> postgres[1]=# select
>> postgres[2]-# *
>> postgres[3]-# from
>> postgres[4]-# hoge;
>>
>> The past discussion is following.
>>
>> <http://www.postgresql.org/message-id/CAFj8pRC1ruPk6+chA1jpxPh3uS_zipaBDOvmcEex4wPbp2kZMQ@mail.gmail.com>
>>
>> Please give me feedback.
>>
>> Regards,
>>
>> -------
>> Sawada Masahiko
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>>
>
>
>
> --
> Jeevan B Chalke
> Principal Software Engineer, Product Development
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: +91 20 30589500
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of the
> individual or entity to whom it is addressed. This message contains
> information from EnterpriseDB Corporation that may be privileged,
> confidential, or exempt from disclosure under applicable law. If you are not
> the intended recipient or authorized to receive this for the intended
> recipient, any use, dissemination, distribution, retention, archiving, or
> copying of this communication is strictly prohibited. If you have received
> this e-mail in error, please notify the sender immediately by reply e-mail
> and delete this message.

Thank you for reviewing patch, and sorry for late response.

I have updated this patch, and attached it.

> postgres[1]=# select
> *
> from
> tab
> postgres[2]-# where t > 10;
> ERROR: column "t" does not exist
> LINE 5: where t > 10;
Attached patch can handle this case.

Please give me feedback.

Regards,

-------
Sawada Masahiko