Re: add line number as prompt option to psql

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add line number as prompt option to psql
Date: 2014-08-14 12:07:11
Message-ID: CAD21AoAJqB=e_fBHzz3pg0qROAacPTgxUw=8ZdHQA-DjVdutNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 12, 2014 at 2:19 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Sawada Masahiko wrote:
>
>> As you said, if line number reached UINT_MAX then I think that this
>> case is too strange.
>> I think INT_MAX is enough for line number.
>
> My point is not whether 2 billion is a better number than 4 billion as a
> maximum value. My point is that wraparound of signed int is, I think,
> not even defined in C, whereas wraparound of unsigned int is well
> defined. cur_line should be declared as unsigned int. I don't trust
> that INT_MAX+2 arithmetic.
>
> Please don't use cur_line as a name for a global variable. Something
> like PSQLLineNumber seems more appropriate if it's going to be exposed
> through prompt.h. However, note that MainLoop() keeps state in local
> variables and notes that it is reentrant; what happens to your cur_line
> when a file is read by \i and similar? I wonder if it should be part of
> PsqlScanStateData instead ...
>

Thank you for comment.
I restarted to make this patch again.

Attached patch is new version patch, and rebased.
pset structure has cur_lineno variable which shows current line number
as unsigned int64.

Regards,

-------
Sawada Masahiko

Attachment Content-Type Size
psql-line-number_v6.patch application/octet-stream 3.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2014-08-14 12:53:05 Re: Improvement of versioning on Windows, take two
Previous Message Fujii Masao 2014-08-14 11:34:09 Re: Support for N synchronous standby servers