Fabien COELHO writes:
>> Probably the easiest fix is to add a rule that explicitly matches this
>> situation:
>> {nonspace}+{continuation} { ... throw back 2 chars and return the rest ... }
> Well, as the continuation characters must be ignored, so there is no need
> to throw them back, just a
You have rules for
{nonspace}+ [...]
{continuation}
Remember that flex always takes the rule that produces the longest match
starting at the current point. {space}+ and {newline} don't conflict with
continuations, but {nonspace}+ does:
Indeed, I totally overlooked "{nonspace
Rafia Sabih writes:
> Okay, I am marking it as 'Ready for committer' with the following note
> to committer,
> I am getting whitespace errors in v3 of patch, which I corrected in
> v4, however, Fabien is of the opinion that v3 is clean and is showing
> whitespace errors because of downloader, etc.
On Fri, Jan 13, 2017 at 9:15 PM, Fabien COELHO wrote:
>
>>> Could it be related to transformations operated when the file is
>>> downloaded
>>> and saved, because it is a text file?
>>
>>
>> I think this is delaying the patch unnecessarily, I have attached a
>> version, please see if you can apply
Could it be related to transformations operated when the file is downloaded
and saved, because it is a text file?
I think this is delaying the patch unnecessarily, I have attached a
version, please see if you can apply it successfully, we can proceed
with that safely then...
This is the same
On Fri, Jan 13, 2017 at 4:57 PM, Fabien COELHO wrote:
>
> Hello Rafia,
>
>>> sh> git apply ~/pgbench-continuation-3.patch
>>> # ok
>>
>>
>> It still gives me whitespace errors with git apply,
>
>
> Strange.
>
Yes, quite strange.
>> /Users/edb/Downloads/pgbench-continuation-3.patch:31: trailin
Hello Rafia,
sh> git apply ~/pgbench-continuation-3.patch
# ok
It still gives me whitespace errors with git apply,
Strange.
/Users/edb/Downloads/pgbench-continuation-3.patch:31: trailing whitespace.
continuation \\{newline}
Looks like an editor issue, I used awk '{ sub("\r$", "");
On Wed, Jan 11, 2017 at 5:39 PM, Fabien COELHO wrote:
>
> Hello,
>
>>> The attached patch adds backslash-return (well newline really)
>>> continuations
>>> to all pgbench backslash-commands.
>>>
>>> The attached test uses continuations on all such commands (sleep set
>>> setshell and shell).
>>>
>
Hello,
The attached patch adds backslash-return (well newline really) continuations
to all pgbench backslash-commands.
The attached test uses continuations on all such commands (sleep set
setshell and shell).
I think that adding continuations to psql should be a distinct patch.
The patch do
On Sat, Dec 3, 2016 at 1:52 PM, Fabien COELHO wrote:
>
>> FWIW, I looked a bit further and concluded that probably psqlscan.l
>> doesn't need to be modified; so likely you could do this across all of
>> pgbench's commands without touching psql. That might be an acceptable
>> compromise for now, t
FWIW, I looked a bit further and concluded that probably psqlscan.l
doesn't need to be modified; so likely you could do this across all of
pgbench's commands without touching psql. That might be an acceptable
compromise for now, though I still think that as soon as we have this
for pgbench, use
On Fri, Dec 2, 2016 at 6:13 AM, Tom Lane wrote:
> Fabien COELHO writes:
> >> In psql, if backslash followed by [CR]LF is interpreted as a
> >> continuation symbol, commands like these seem problematic
> >> on Windows since backslash is the directory separator:
> >>
> >> \cd \
> >> \cd c:\somepat
Fabien COELHO writes:
>> In psql, if backslash followed by [CR]LF is interpreted as a
>> continuation symbol, commands like these seem problematic
>> on Windows since backslash is the directory separator:
>>
>> \cd \
>> \cd c:\somepath\
>>
>> Shell invocations also come to mind:
>> \! dir \
> T
Hello Daniel,
- if not, are possible corner case backward incompatibilities introduced
by such feature ok?
In psql, if backslash followed by [CR]LF is interpreted as a
continuation symbol, commands like these seem problematic
on Windows since backslash is the directory separator:
\cd \
\
Fabien COELHO wrote:
> - if not, are possible corner case backward incompatibilities introduced
>by such feature ok?
In psql, if backslash followed by [CR]LF is interpreted as a
continuation symbol, commands like these seem problematic
on Windows since backslash is the directory sepa
Hello Tom,
[...]
I definitely agree that having homogeneous continuations on every
backslash commands is better, but this has a cost in code lines and
possible backward compatibilities. This is the kind of thing better
addressed in the initial design rather than long afterwards...
FWIW,
Fabien COELHO writes:
>> In short, I want to mark this RWF for today and ask for a version that
>> applies globally to all backslash commands in psql and pgbench.
> I'm not sure such a simple feature deserves so much energy.
It's not a "simple feature". As you have it, it's a non-orthogonal war
Hello Tom,
In short, I want to mark this RWF for today and ask for a version that
applies globally to all backslash commands in psql and pgbench.
Hmmm.
The modus operandi of backslash command scanning is to switch to possibly
another scanner just after scanning the backslash command, so I d
Rafia Sabih writes:
> On Wed, Nov 9, 2016 at 3:28 PM, Fabien COELHO wrote:
+1. My vote is for backslash continuations.
>> I'm fine with that!
> Looks good to me also.
I concur that we don't want implicit continuation; that creates too many
special cases and will certainly fail to general
On Wed, Nov 9, 2016 at 3:28 PM, Fabien COELHO wrote:
>
> +1. My vote is for backslash continuations.
>>
>
> I'm fine with that!
>
> --
> Fabien.
>
Looks good to me also.
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
+1. My vote is for backslash continuations.
I'm fine with that!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 8, 2016 at 5:33 AM, Fabien COELHO wrote:
> I do not think that having both inferred continuations and explicit
> backslash continuations is desirable, it should be one or the other.
+1. My vote is for backslash continuations. Inferred continuations
require you to end your expression
Hello Rafia,
Please keep copying to the list.
Though I find the first version of this patch acceptable in terms that it
would be helpful on enhancing the readability of expressions as you
mentioned. However, the second version is not clear as I mentioned before
also, there has to be detailed d
Hello Rafia,
Well with this new approach, the example you gave previously for better
readability:
\set bid
CASE WHEN random(0, 99) < 85
THEN :tbid
ELSE :abid + (:abid >= :tbid)
END
will give error at the first line.
Indeed you are right for the patch I sent, but it
Well with this new approach, the example you gave previously for better
readability:
> \set bid
> CASE WHEN random(0, 99) < 85
>THEN :tbid
>ELSE :abid + (:abid >= :tbid)
> END
will give error at the first line. In general, this new approach is likely
to create confusions
Attached patch does what is described in the title, hopefully. Continuations
in other pgbench backslash-commands should be dealt with elsewhere...
Also attached is a small test script.
Here is another approach, with "infered" continuations: no backslash is
needed, the parsing is pursued if
Hello Rafia,
Seems like an interesting addition to pgbench interface, but not sure where
it's required, it'll be good if you may provide some cases where it's
utility can be witnessed. Something like where you absolutely need
continuations in expression.
It is never "absolutely needed", you c
Hie Fabien,
Seems like an interesting addition to pgbench interface, but not sure where
it's required, it'll be good if you may provide some cases where it's
utility can be witnessed. Something like where you absolutely need
continuations in expression.
While applying it is giving some trailing wh
Re: Fabien COELHO 2016-10-03
> > I "\set" a bunch of lengthy SQL commands in there, e.g.
>
> I agree that this looks like a desirable feature, however I would tend to
> see that as material for another independent patch.
Sure, my question was by no means intending to stop your pgbench patch
from
Hello Christoph,
Attached patch does what is described in the title, hopefully. Continuations
in other pgbench backslash-commands should be dealt with elsewhere...
Would (a similar version of) that patch also apply to .psqlrc?
Pgbench has its own lexer & parser for \set expressions, so the
Re: Fabien COELHO 2016-10-03
>
> Attached patch does what is described in the title, hopefully. Continuations
> in other pgbench backslash-commands should be dealt with elsewhere...
Would (a similar version of) that patch also apply to .psqlrc? I
"\set" a bunch of lengthy SQL commands in there,
31 matches
Mail list logo
