Обсуждение: Windows v readline
The configure code currently has this: # readline on MinGW has problems with backslashes in psql and other bugs. # This is particularly a problem with non-US code pages. # Therefore disable its use until we understand the cause. 2004-07-20 if test "$PORTNAME" = "win32"; then if test "$with_readline" = yes; then AC_MSG_WARN([*** Readline does not work on MinGW --- disabling]) with_readline=no fi fi 2004 is a very long time ago. Has anyone looked at this more recently? It would certainly be nice to have readline-enabled psql on Windows if possible. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I found some problem with tab-complete in the 12 version. I checked this in the Windows. Victor Spirin Postgres Professional:http://www.postgrespro.com The Russian Postgres Company
Вложения
Sorry for wrong place and contents of my message. It seems that the VA_ARGS_NARGS (__ VA_ARGS__) macros always return 1 on Windows. Victor Spirin Postgres Professional:http://www.postgrespro.com The Russian Postgres Company 24.10.2019 19:11, Victor Spirin пишет: > I found some problem with tab-complete in the 12 version. I checked > this in the Windows. > > > Victor Spirin > Postgres Professional:http://www.postgrespro.com > The Russian Postgres Company > >
Victor Spirin <v.spirin@postgrespro.ru> writes:
> I found some problem with tab-complete in the 12 version. I checked
> this in the Windows.
This change seems to break the case intended by the comment,
ie given the context
SELECT * FROM tablename WHERE <tab>
we want to offer the columns of "tablename" as completions.
I'd be the first to agree that that's completely lame, as there
are any number of related cases it fails to cover ... but this
patch isn't making it better.
regards, tom lane
Yes, I found, that VA_ARGS_NARGS(__ VA_ARGS__) macros always return 1 on Windows. Victor Spirin Postgres Professional:http://www.postgrespro.com The Russian Postgres Company 25.10.2019 0:48, Tom Lane пишет: > Victor Spirin <v.spirin@postgrespro.ru> writes: >> I found some problem with tab-complete in the 12 version. I checked >> this in the Windows. > This change seems to break the case intended by the comment, > ie given the context > > SELECT * FROM tablename WHERE <tab> > > we want to offer the columns of "tablename" as completions. > > I'd be the first to agree that that's completely lame, as there > are any number of related cases it fails to cover ... but this > patch isn't making it better. > > regards, tom lane > >
This patch resolved one problem in the tab-complete.c on MSVC. The VA_ARGS_NARGS macros now work correctly on Windows. Victor Spirin Postgres Professional:http://www.postgrespro.com The Russian Postgres Company 25.10.2019 0:53, Victor Spirin пишет: > Yes, I found, that VA_ARGS_NARGS(__ VA_ARGS__) macros always return 1 > on Windows. > > Victor Spirin > Postgres Professional:http://www.postgrespro.com > The Russian Postgres Company > > 25.10.2019 0:48, Tom Lane пишет: >> Victor Spirin <v.spirin@postgrespro.ru> writes: >>> I found some problem with tab-complete in the 12 version. I checked >>> this in the Windows. >> This change seems to break the case intended by the comment, >> ie given the context >> >> SELECT * FROM tablename WHERE <tab> >> >> we want to offer the columns of "tablename" as completions. >> >> I'd be the first to agree that that's completely lame, as there >> are any number of related cases it fails to cover ... but this >> patch isn't making it better. >> >> regards, tom lane >> >> > >
Вложения
On Fri, Oct 25, 2019 at 11:57:18AM +0300, Victor Spirin wrote: > This patch resolved one problem in the tab-complete.c on MSVC. The > VA_ARGS_NARGS macros now work correctly on Windows. Can you explain why and in what the use of EXPAND() helps with MSVC builds? Any references which help to understand why this is better? If this change is needed, this also surely needs a comment to explain the difference. -- Michael
Вложения
On 2019-09-29 22:55, Andrew Dunstan wrote: > > The configure code currently has this: > > > # readline on MinGW has problems with backslashes in psql and other bugs. > # This is particularly a problem with non-US code pages. > # Therefore disable its use until we understand the cause. 2004-07-20 > if test "$PORTNAME" = "win32"; then > if test "$with_readline" = yes; then > AC_MSG_WARN([*** Readline does not work on MinGW --- disabling]) > with_readline=no > fi > fi > > > 2004 is a very long time ago. Has anyone looked at this more recently? > It would certainly be nice to have readline-enabled psql on Windows if > possible. I tried this out. First, it doesn't build, because readline doesn't do the dllimport/dllexport dance on global variables, so all references to rl_* global variables in tab-complete.c fail (similar to [0]). After patching those out, it builds, but it doesn't work. It doesn't print a prompt, keys don't do anything sensible. I can enter SQL commands and get results back, but the readline part doesn't do anything sensible AFAICT. Perhaps I did something wrong. You can still use readline without global variables, but it seems like a serious restriction and makes me wonder whether this has actually ever been used before. It's curious that MSYS2 ships a readline build for mingw. Is there other software that uses it on Windows? [0]: https://www.postgresql.org/message-id/001101c3eb6a$3b275500$f800a8c0@kuczek.pl -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-09-29 22:55, Andrew Dunstan wrote:
>> It would certainly be nice to have readline-enabled psql on Windows if
>> possible.
> I tried this out. First, it doesn't build, because readline doesn't do
> the dllimport/dllexport dance on global variables, so all references to
> rl_* global variables in tab-complete.c fail (similar to [0]). After
> patching those out, it builds, but it doesn't work.
What do you mean by "patching those out" --- you removed all of
tab-complete's external variable assignments? That would certainly
disable tab completion, at a minimum.
> It doesn't print a
> prompt, keys don't do anything sensible. I can enter SQL commands and
> get results back, but the readline part doesn't do anything sensible AFAICT.
I wonder if readline was confused about the terminal type, or if it
decided that the input file was not-a-tty for some reason.
regards, tom lane
On 2019-12-30 14:28, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> On 2019-09-29 22:55, Andrew Dunstan wrote: >>> It would certainly be nice to have readline-enabled psql on Windows if >>> possible. > >> I tried this out. First, it doesn't build, because readline doesn't do >> the dllimport/dllexport dance on global variables, so all references to >> rl_* global variables in tab-complete.c fail (similar to [0]). After >> patching those out, it builds, but it doesn't work. > > What do you mean by "patching those out" --- you removed all of > tab-complete's external variable assignments? That would certainly > disable tab completion, at a minimum. Yeah, basically remove tab completion altogether. But readline would still be useful without that for line editing and history. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Oct 26, 2019 at 4:59 PM Michael Paquier <michael@paquier.xyz> wrote: > On Fri, Oct 25, 2019 at 11:57:18AM +0300, Victor Spirin wrote: > > This patch resolved one problem in the tab-complete.c on MSVC. The > > VA_ARGS_NARGS macros now work correctly on Windows. > > Can you explain why and in what the use of EXPAND() helps with MSVC > builds? Any references which help to understand why this is better? > If this change is needed, this also surely needs a comment to explain > the difference. Since I really want to be able to use VA_ARGS_NARGS() elsewhere, I looked into this. There are various derivatives of that macro, some using GCC/Clang-only syntax and that work on GCC and MSVC, splattered all over the internet, but the original, coming as it does from a C standards newsgroup[1], does not. There are also lots of complaints that the original standard version doesn't work on MSVC, with analysis: https://stackoverflow.com/questions/5134523/msvc-doesnt-expand-va-args-correctly https://stackoverflow.com/questions/32399191/va-args-expansion-using-msvc https://learn.microsoft.com/en-us/cpp/build/reference/zc-preprocessor?view=msvc-170 The short version is that __VA_ARGS__ is not tokenized the way the standard requires (it's considered to be a single token unless you shove it back through the preprocessor again, which is what EXPAND() does), but you can fix that with /Zc:preprocessor. That switch only works in Visual Studio 2019 and up, and maybe also 2017 if you spell it /experimental:preprocessor. We still claim to support older compilers. Assuming those switches actually work as claimed, I see two choices: commit this hack with a comment reminding us to clean it up later, or drop 2015. [1] https://groups.google.com/g/comp.std.c/c/d-6Mj5Lko_s
Thomas Munro <thomas.munro@gmail.com> writes:
> Since I really want to be able to use VA_ARGS_NARGS() elsewhere,
+1, that'd be handy.
> ... Assuming those switches actually work as claimed, I see
> two choices: commit this hack with a comment reminding us to clean it
> up later, or drop 2015.
As long as we can hide the messiness inside a macro definition,
I'd vote for the former.
regards, tom lane
On Wed, Dec 21, 2022 at 05:56:05PM -0500, Tom Lane wrote: > Thomas Munro <thomas.munro@gmail.com> writes: >> Since I really want to be able to use VA_ARGS_NARGS() elsewhere, > > +1, that'd be handy. > >> ... Assuming those switches actually work as claimed, I see >> two choices: commit this hack with a comment reminding us to clean it >> up later, or drop 2015. > > As long as we can hide the messiness inside a macro definition, > I'd vote for the former. Agreed, even if it is worth noting that all the buildfarm members with MSVC use 2017 or newer. -- Michael
Вложения
On Thu, Dec 22, 2022 at 3:25 PM Michael Paquier <michael@paquier.xyz> wrote: > On Wed, Dec 21, 2022 at 05:56:05PM -0500, Tom Lane wrote: > > Thomas Munro <thomas.munro@gmail.com> writes: > >> Since I really want to be able to use VA_ARGS_NARGS() elsewhere, > > > > +1, that'd be handy. > > > >> ... Assuming those switches actually work as claimed, I see > >> two choices: commit this hack with a comment reminding us to clean it > >> up later, or drop 2015. > > > > As long as we can hide the messiness inside a macro definition, > > I'd vote for the former. > > Agreed, even if it is worth noting that all the buildfarm members > with MSVC use 2017 or newer. Thanks. Pushed. PS is it a mistake that we still mention SDK 8.1 in the docs?