On 2014-09-02 12:34:12 +0900, Sawada Masahiko wrote:
> On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote:
> > I've now used up a perfectly good glass of wine for this, so this is it
> > for today ;)
> >
>
> Thank you for updating the patch!
> I tested it.
> These fix looks good to me :)
Commi
On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote:
> On 2014-08-31 12:06:31 +0900, Sawada Masahiko wrote:
>> Thank you for review comment and improving the patch!
>> I tested it.
>> Your patch always increment line number even if there is no input line
>> as follows.
>>
>> postgres[1]=#
>> post
On 2014-09-02 11:19:09 +0900, Michael Paquier wrote:
> On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote:
> > I've now used up a perfectly good glass of wine for this.
> Red or white? From where? Useful tips for hacking in this area are
> always useful.
Hah ;). Nothing special, but I rather li
On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote:
> I've now used up a perfectly good glass of wine for this.
Red or white? From where? Useful tips for hacking in this area are
always useful.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 2014-08-31 12:06:31 +0900, Sawada Masahiko wrote:
> Thank you for review comment and improving the patch!
> I tested it.
> Your patch always increment line number even if there is no input line
> as follows.
>
> postgres[1]=#
> postgres[2]=# select
> postgres[3]-# ,
> postgres[4]-# from
> postg
On Tue, Aug 26, 2014 at 10:23 PM, Andres Freund wrote:
> On 2014-08-21 11:43:48 +0900, Sawada Masahiko wrote:
>> On Wed, Aug 20, 2014 at 9:00 PM, Jeevan Chalke
>> wrote:
>> > Hi,
>> >
>> > I have reviewed this:
>> >
>> > I have initialize cur_lineno to UINTMAX - 2. And then observed following
>>
On 2014-08-21 11:43:48 +0900, Sawada Masahiko wrote:
> On Wed, Aug 20, 2014 at 9:00 PM, Jeevan Chalke
> 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
> 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.
>
> Yeah, most likely you will run out of memory before reaching that point,
> or out of patience.
>
> Yep.
BTW, I have marked this as "waiting for committer".
Thanks
Jeevan Chalke wrote:
> 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[1844674407
On Wed, Aug 20, 2014 at 9:00 PM, Jeevan Chalke
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%#
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[184467440737095516
On Sat, Jul 12, 2014 at 2:19 AM, Alvaro Herrera
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
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
On Fri, Jul 11, 2014 at 11:01 PM, Alvaro Herrera
wrote:
> Jeevan Chalke wrote:
>
>> On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko
>> wrote:
>
>> > And the line number should be switched to 1 when line number has
>> > reached to INT_MAX?
>>
>> Yes, when it goes beyond INT_MAX, wrap around to 1.
Jeevan Chalke wrote:
> On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko
> wrote:
> > And the line number should be switched to 1 when line number has
> > reached to INT_MAX?
>
> Yes, when it goes beyond INT_MAX, wrap around to 1.
>
> BTW, I wonder, can't we simply use unsigned int instead?
Th
Hi,
On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko
wrote:
> >
> >
>
> To my understating cleanly, you means that line number is not changed
> when newline has reached to INT_MAX, is incorrect?
>
As per my thinking yes.
> And the line number should be switched to 1 when line number has
> re
On Fri, Jul 11, 2014 at 4:23 PM, Jeevan Chalke
wrote:
> Hi,
>
> A.
>
> However, this introduced new bug. As I told, when editor number of lines
> reaches INT_MAX it starts giving negative number. You tried overcoming this
> issue by adding "< 0" check. But I guess you again fumbled in setting that
Hi,
Found new issues with latest patch:
> Thank you for reviewing the patch with variable cases.
> I have revised the patch, and attached latest patch.
>
> > A:
> > Will you please explain the idea behind these changes ?
> I thought wrong about adding new to tail of query_buf.
> The latest patch
On Thu, Jul 10, 2014 at 8:35 PM, Jeevan Chalke
wrote:
> Hi,
>
> Found few more bugs in new code:
>
> A:
> This got bad:
>
> jeevan@ubuntu:~/pg_master$ ./install/bin/psql postgres
> psql (9.5devel)
> Type "help" for help.
>
>
> postgres=# \set PROMPT1 '%/[%l]%R%# '
> postgres[1]=# \set PROMPT2 '%/[
Hi,
Found few more bugs in new code:
A:
This got bad:
jeevan@ubuntu:~/pg_master$ ./install/bin/psql postgres
psql (9.5devel)
Type "help" for help.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
postgres[1]=# select
postgres[2]-# *
postgres[3]-# from
postgres[4]-#
On Mon, Jul 7, 2014 at 8:33 PM, Jeevan Chalke
wrote:
> Hi,
>
> Found two (A and B) issues with latest patch:
>
> A:
> -- Set prompts
> postgres=# \set PROMPT1 '%/[%l]%R%# '
> postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
>
> postgres[1]=#
> postgres[1]=# select
> postgres[2]-# *
> postgres[3]-# from
>
Hi,
Found two (A and B) issues with latest patch:
A:
-- Set prompts
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
postgres[1]=#
postgres[1]=# select
postgres[2]-# *
postgres[3]-# from
postgres[4]-# abc;
ERROR: relation "abc" does not exist
LINE 4: abc;
^
On Fri, Jun 20, 2014 at 7:17 PM, Jeevan Chalke
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 i
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
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 occurre
25 matches
Mail list logo