Peter Eisentraut writes:
> On 2020-01-14 02:38, Tom Lane wrote:
>> On reflection, it seems like the best bet for the moment is to
>> remove double-quote from the rl_completer_quote_characters string,
>> which should restore all behavior around double-quoted strings to
>> what it was before. (We
On 2020-01-14 02:38, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
I have found a weird behavior with identifier quoting, which is not the
subject of this patch, but it appears to be affected by it.
I'll think about how to improve this. Given that we're dequoting
filenames explicitly
I wrote:
> Peter Eisentraut writes:
>> I have found a weird behavior with identifier quoting, which is not the
>> subject of this patch, but it appears to be affected by it.
> I'll think about how to improve this. Given that we're dequoting
> filenames explicitly anyway, maybe we don't need to
Peter Eisentraut writes:
> The file name completion portion of this patch seems to work quite well now.
Thanks for testing!
> I have found a weird behavior with identifier quoting, which is not the
> subject of this patch, but it appears to be affected by it.
> The good thing is that the new
On 2020-01-06 07:06, Tom Lane wrote:
Hence, the attached revision only forces quoting in a SQL COPY
command, or if the user already typed a quote.
Yes, that seems better. Users tend to not like if tab completion messes
with what they have already typed unless strictly necessary.
The file
I wrote:
> Peter Eisentraut writes:
>> I haven't found an explanation in this thread why it does always quote
>> now. That seems a bit unusual. Is there a reason for this? Can we do
>> without it?
> The core problem we're trying to solve is stated in the thread title:
> ...
> It'd be
Peter Eisentraut writes:
> On 2019-11-03 23:40, Tom Lane wrote:
>> * The patch now always quotes completed filenames, so quote_if_needed()
>> is misnamed and overcomplicated for this use-case. I left the extra
>> generality in place for possible future use. On the other hand, this
>> is
On 2019-11-03 23:40, Tom Lane wrote:
* The patch now always quotes completed filenames, so quote_if_needed()
is misnamed and overcomplicated for this use-case. I left the extra
generality in place for possible future use. On the other hand, this
is the*only* use-case, so you could also argue
Alvaro Herrera writes:
> One minor thing I noticed is that if I enter
> \copy t from '/tmp/t'
> and I have files /tmp/t and /tmp/tst then it removes the ending quote.
Yeah, that bothered me too. [ pokes at it for a bit... ] The
quote_file_name function isn't passed enough info to handle this
On 2019-Dec-27, Tom Lane wrote:
> I wrote:
> > [ psql-filename-completion-fixes-2.patch ]
>
> The cfbot noted this was broken by the removal of pg_config.h.win32,
> so here's a new version rebased over that. No changes other than
> adjusting the MSVC autoconf-substitute code.
Works well for
I wrote:
> [ psql-filename-completion-fixes-2.patch ]
The cfbot noted this was broken by the removal of pg_config.h.win32,
so here's a new version rebased over that. No changes other than
adjusting the MSVC autoconf-substitute code.
regards, tom lane
diff --git
Alvaro Herrera writes:
> I suggest to indicate in complete_from_files where to find the hook
> functions it refers to (say "see quote_file_name, below", or something.)
Done.
> I tested this on libreadline 7.x (where #define
> HAVE_RL_FILENAME_COMPLETION_FUNCTION 1). I noticed that if I enter a
I wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2019 at 10:52 AM Tom Lane wrote:
>>> I think it's Debian's problem, not ours, if that doesn't work. It is
>>> not unreasonable for a package to probe existence of a library function
>>> at configure time. It's up to them to make sure that the
Alvaro Herrera writes:
> On 2019-Dec-13, Tom Lane wrote:
>> A possible further change is to switch the code over to calling
>> "rl_filename_completion_function", and then invert the sense of
>> this logic, like ...
> +1, I think that's clearer.
OK, I went ahead and pushed that change, since it
On 2019-Dec-13, Tom Lane wrote:
> I wrote:
> >> Alvaro Herrera writes:
> >>> #ifdef HAVE_RL_FILENAME_COMPLETION_FUNCTION
> >>> #define filename_completion_function rl_filename_completion_function
> >>> #else
> >>> /* decl missing in some header files, but function exists anyway */
> >>> extern
I wrote:
>> Alvaro Herrera writes:
>>> I don't quite understand why a readline library that doesn't have
>>> rl_filename_completion_function is known to have a
>>> filename_completion_function, ie. this bit
>>> #ifdef HAVE_RL_FILENAME_COMPLETION_FUNCTION
>>> #define filename_completion_function
I wrote:
> Alvaro Herrera writes:
>> I don't quite understand why a readline library that doesn't have
>> rl_filename_completion_function is known to have a
>> filename_completion_function, ie. this bit
>> #ifdef HAVE_RL_FILENAME_COMPLETION_FUNCTION
>> #define filename_completion_function
Alvaro Herrera writes:
> I tested this on libreadline 7.x (where #define
> HAVE_RL_FILENAME_COMPLETION_FUNCTION 1). I noticed that if I enter a
> filename that doesn't exist and then , it adds a closing quote.
> Bash manages to do nothing somehow, which is the desired behavior IMO.
Hmm. I'll
Robert Haas writes:
> On Wed, Dec 11, 2019 at 10:52 AM Tom Lane wrote:
>> I think it's Debian's problem, not ours, if that doesn't work. It is
>> not unreasonable for a package to probe existence of a library function
>> at configure time. It's up to them to make sure that the headers match
>>
On Wed, Dec 11, 2019 at 10:52 AM Tom Lane wrote:
> I think it's Debian's problem, not ours, if that doesn't work. It is
> not unreasonable for a package to probe existence of a library function
> at configure time. It's up to them to make sure that the headers match
> the actual library.
That
Alvaro Herrera writes:
> On 2019-Dec-11, Robert Haas wrote:
>> Are people still compiling against libedit and then redirecting to
>> libreadline at runtime? I seem to recall some discussion about this
>> being a thing, many years ago.
> Yeah, Debian did that out of licensing concerns. It seems
On 2019-Dec-11, Alvaro Herrera wrote:
> On 2019-Dec-11, Robert Haas wrote:
> > If it were being done it would be
> > advantageous to have the checks be runtime rather than compile-time,
> > although I guess that would probably be tough to make work.
>
> Yeah. On the other hand, I suppose
On 2019-Dec-11, Robert Haas wrote:
> On Sun, Nov 3, 2019 at 5:40 PM Tom Lane wrote:
> > Of course, this only works if we have those hooks :-(. So far as
> > I can tell, all libreadline variants that might still exist in the wild
> > do have them; but libedit doesn't, at least not in the version
On Sun, Nov 3, 2019 at 5:40 PM Tom Lane wrote:
> Of course, this only works if we have those hooks :-(. So far as
> I can tell, all libreadline variants that might still exist in the wild
> do have them; but libedit doesn't, at least not in the version Apple
> is shipping. Hence, what the
All in all, after testing this for a bit, I think this patch is a clear
improvement over the statu quo. Thanks for working on this.
I suggest to indicate in complete_from_files where to find the hook
functions it refers to (say "see quote_file_name, below", or something.)
I tested this on
[ redirecting to -hackers ]
I wrote:
> Yeah, it seems like a bad idea to override the user's choice to write
> a quote, even if one is not formally necessary. I propose the attached.
After further experimentation, I concluded that that patch is a bad idea;
it breaks a lot of cases that used to
26 matches
Mail list logo
