Re: .psqlrc version dependence (was Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH)
Tom Lane wrote: > Peter Eisentraut writes: > > Contrary to what the subject suggests, I think the main reason people > > wanted this feature was to be able to set the linestyle to unicode > > without getting a warning from older releases about unknown linestyle or > > something. But in a few years, they'll have to > > maintain .psqlrc-9.2, .psqlrc-9.3, .psqlrc-9.4, etc. That doesn't sound > > like a useful long-term solution either. > > Well, "in a few years" they won't need that conditionality any more at > all, so I'm not sure I believe the above argument. The problem seems > inherently self-limiting. > > What struck me while looking at the patch is that it is conditional > based on *psql's* version. Not the version of the server you're > connected to. I'm not too sure what use-cases people have for version > dependence here, but I'd think that the server version would enter into > it sometimes. The assumption is that the .psqlrc is controlling psql behavior. Not sure what setting would be changed based on server version, maybe psql variables. I have updated the docs to indicate it is the psql version. > (Of course, for server version to be used usefully, you'd need to > re-execute the rc file during \c, something we don't do now.) Yep, yuck. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
.psqlrc version dependence (was Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH)
Peter Eisentraut writes: > Contrary to what the subject suggests, I think the main reason people > wanted this feature was to be able to set the linestyle to unicode > without getting a warning from older releases about unknown linestyle or > something. But in a few years, they'll have to > maintain .psqlrc-9.2, .psqlrc-9.3, .psqlrc-9.4, etc. That doesn't sound > like a useful long-term solution either. Well, "in a few years" they won't need that conditionality any more at all, so I'm not sure I believe the above argument. The problem seems inherently self-limiting. What struck me while looking at the patch is that it is conditional based on *psql's* version. Not the version of the server you're connected to. I'm not too sure what use-cases people have for version dependence here, but I'd think that the server version would enter into it sometimes. (Of course, for server version to be used usefully, you'd need to re-execute the rc file during \c, something we don't do now.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Andrew Dunstan wrote: > > > On 10/15/2011 09:37 AM, Peter Eisentraut wrote: > > On tor, 2011-10-13 at 11:31 -0400, Bruce Momjian wrote: > >> The attached patch changes this to use the _major_ version number for > >> psql rc files. Does this have to be backward-compatible? Should I > >> check for minor and major matches? That is going to be confusing to > >> document. > > Contrary to what the subject suggests, I think the main reason people > > wanted this feature was to be able to set the linestyle to unicode > > without getting a warning from older releases about unknown linestyle or > > something. But in a few years, they'll have to > > maintain .psqlrc-9.2, .psqlrc-9.3, .psqlrc-9.4, etc. That doesn't sound > > like a useful long-term solution either. > > > > > > Wouldn't it be better to support some conditional syntax? I suppose if we add that to psql we can remove this factility completely. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Peter Eisentraut wrote: > On tor, 2011-10-13 at 11:31 -0400, Bruce Momjian wrote: > > The attached patch changes this to use the _major_ version number for > > psql rc files. Does this have to be backward-compatible? Should I > > check for minor and major matches? That is going to be confusing to > > document. > > Contrary to what the subject suggests, I think the main reason people > wanted this feature was to be able to set the linestyle to unicode > without getting a warning from older releases about unknown linestyle or > something. But in a few years, they'll have to > maintain .psqlrc-9.2, .psqlrc-9.3, .psqlrc-9.4, etc. That doesn't sound > like a useful long-term solution either. Well, frankly, I think the fact we were matching on minor version number was even worse. This is slightly better. I guess they could use symlinks to keep a config file for multiple versions, but I agree it isn't a long-term great solution. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On 10/15/2011 09:37 AM, Peter Eisentraut wrote: On tor, 2011-10-13 at 11:31 -0400, Bruce Momjian wrote: The attached patch changes this to use the _major_ version number for psql rc files. Does this have to be backward-compatible? Should I check for minor and major matches? That is going to be confusing to document. Contrary to what the subject suggests, I think the main reason people wanted this feature was to be able to set the linestyle to unicode without getting a warning from older releases about unknown linestyle or something. But in a few years, they'll have to maintain .psqlrc-9.2, .psqlrc-9.3, .psqlrc-9.4, etc. That doesn't sound like a useful long-term solution either. Wouldn't it be better to support some conditional syntax? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On tor, 2011-10-13 at 11:31 -0400, Bruce Momjian wrote: > The attached patch changes this to use the _major_ version number for > psql rc files. Does this have to be backward-compatible? Should I > check for minor and major matches? That is going to be confusing to > document. Contrary to what the subject suggests, I think the main reason people wanted this feature was to be able to set the linestyle to unicode without getting a warning from older releases about unknown linestyle or something. But in a few years, they'll have to maintain .psqlrc-9.2, .psqlrc-9.3, .psqlrc-9.4, etc. That doesn't sound like a useful long-term solution either. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Tom Lane wrote: > Bruce Momjian writes: > > Oops, I see a problem. Right now, our first major release has no zero, > > e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is > > that with this patch it is confusing to have a psql config file that > > matches 9.2.0, but not 9.2.5, because you can't write 9.2.0. > > Uh, this seems like nonsense. We've been labeling major releases with > a dot-zero for some time, and that's embedded in process now (cf > version_stamp.pl) to the point that we're unlikely to forget to do so. Ah, I see now. 9.1 has: #define PG_VERSION "9.1.0" I rarely see the non-dev trees. No problem then. Patch applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Bruce Momjian writes: > Oops, I see a problem. Right now, our first major release has no zero, > e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is > that with this patch it is confusing to have a psql config file that > matches 9.2.0, but not 9.2.5, because you can't write 9.2.0. Uh, this seems like nonsense. We've been labeling major releases with a dot-zero for some time, and that's embedded in process now (cf version_stamp.pl) to the point that we're unlikely to forget to do so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Alvaro Herrera wrote: > > Excerpts from Robert Haas's message of vie oct 14 09:36:47 -0300 2011: > > > > On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote: > > > Alvaro Herrera wrote: > > > >> Oh, true, we have that, though it's not very usable because you have to > > >> rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when you upgrade, > > >> which is kinda silly. > > > > > > True. ??We don't add configuration changes in minor versions so having > > > minor-version granularity makes no sense. > > > > > > The attached patch changes this to use the _major_ version number for > > > psql rc files. ??Does this have to be backward-compatible? ??Should I > > > check for minor and major matches? ??That is going to be confusing to > > > document. > > > > Checking for a minor match and then a major match seems sensible. > > And backwards compatible too! +1 to that. An idea that you can > describe in six words doesn't seem all that confusing. Oops, I see a problem. Right now, our first major release has no zero, e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is that with this patch it is confusing to have a psql config file that matches 9.2.0, but not 9.2.5, because you can't write 9.2.0. A file called .psql-9.2 matches 9.2.0, but also matches 9.2.X if there is no matching minor release file. The bottom line is that with this patch, .psql-9.2 is both a minor and possibly minor matcher. I can't blame the patch, but rather our version numbering system. Prior to the patch 9.2 always meant just 9.2.0. This patch adds an additional confusion. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Excerpts from Robert Haas's message of vie oct 14 09:36:47 -0300 2011: > > On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote: > > Alvaro Herrera wrote: > >> Oh, true, we have that, though it's not very usable because you have to > >> rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when you upgrade, > >> which is kinda silly. > > > > True. We don't add configuration changes in minor versions so having > > minor-version granularity makes no sense. > > > > The attached patch changes this to use the _major_ version number for > > psql rc files. Does this have to be backward-compatible? Should I > > check for minor and major matches? That is going to be confusing to > > document. > > Checking for a minor match and then a major match seems sensible. And backwards compatible too! +1 to that. An idea that you can describe in six words doesn't seem all that confusing. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Robert Haas wrote: > On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote: > > Alvaro Herrera wrote: > >> Excerpts from Tom Lane's message of mi? may 25 16:07:55 -0400 2011: > >> > Alvaro Herrera writes: > >> > > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011: > >> > >> Right. ?It would also increase the cognitive load on the user to have > >> > >> to remember the command-line go-to-line-number switch for his editor. > >> > >> So I don't particularly want to redesign this feature. ?However, I can > >> > >> see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from > >> > >> the same place that you set EDITOR, which would suggest that we allow > >> > >> the value to come from an environment variable. ?I'm not sure whether > >> > >> there is merit in allowing both that source and ~/.psqlrc, though > >> > >> possibly for Windows users it might be easier if ~/.psqlrc worked. > >> > > >> > > If we're going to increase the number of options in .psqlrc that do not > >> > > work with older psql versions, can I please have .psqlrc-MAJORVERSION > >> > > or > >> > > some such? ?Having 8.3's psql complain all the time because it doesn't > >> > > understand "linestyle" is annoying. > >> > > >> > 1. I thought we already did have that. > >> > >> Oh, true, we have that, though it's not very usable because you have to > >> rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when you upgrade, > >> which is kinda silly. > > > > True. ?We don't add configuration changes in minor versions so having > > minor-version granularity makes no sense. > > > > The attached patch changes this to use the _major_ version number for > > psql rc files. ?Does this have to be backward-compatible? ?Should I > > check for minor and major matches? ?That is going to be confusing to > > document. > > Checking for a minor match and then a major match seems sensible. Done, and documented in the attached patch. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index 662eab7..4eefe3b *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** PSQL_EDITOR_LINENUMBER_ARG='--line ' *** 3332,3339 Both the system-wide psqlrc file and the user's ~/.psqlrc file can be made version-specific by appending a dash and the PostgreSQL ! release number, for example ~/.psqlrc-&version;. ! A matching version-specific file will be read in preference to a non-version-specific file. --- 3332,3341 Both the system-wide psqlrc file and the user's ~/.psqlrc file can be made version-specific by appending a dash and the PostgreSQL ! major or minor release number, for example ! ~/.psqlrc-9.2 or ! ~/.psqlrc-9.2.5. The most specific ! version-matching file will be read in preference to a non-version-specific file. diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c new file mode 100644 index 3c17eec..71829eb *** a/src/bin/psql/startup.c --- b/src/bin/psql/startup.c *** process_psqlrc(char *argv0) *** 594,613 static void process_psqlrc_file(char *filename) { ! char *psqlrc; #if defined(WIN32) && (!defined(__MINGW32__)) #define R_OK 4 #endif ! psqlrc = pg_malloc(strlen(filename) + 1 + strlen(PG_VERSION) + 1); ! sprintf(psqlrc, "%s-%s", filename, PG_VERSION); ! if (access(psqlrc, R_OK) == 0) ! (void) process_file(psqlrc, false, false); else if (access(filename, R_OK) == 0) (void) process_file(filename, false, false); ! free(psqlrc); } --- 594,620 static void process_psqlrc_file(char *filename) { ! char *psqlrc_minor, *psqlrc_major; #if defined(WIN32) && (!defined(__MINGW32__)) #define R_OK 4 #endif ! psqlrc_minor = pg_malloc(strlen(filename) + 1 + strlen(PG_VERSION) + 1); ! sprintf(psqlrc_minor, "%s-%s", filename, PG_VERSION); ! psqlrc_major = pg_malloc(strlen(filename) + 1 + strlen(PG_MAJORVERSION) + 1); ! sprintf(psqlrc_major, "%s-%s", filename, PG_MAJORVERSION); ! /* check for minor version first, then major, then no version */ ! if (access(psqlrc_minor, R_OK) == 0) ! (void) process_file(psqlrc_minor, false, false); ! else if (access(psqlrc_major, R_OK) == 0) ! (void) process_file(psqlrc_major, false, false); else if (access(filename, R_OK) == 0) (void) process_file(filename, false, false); ! ! free(psqlrc_minor); ! free(psqlrc_major); } -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote: > Alvaro Herrera wrote: >> Excerpts from Tom Lane's message of mié may 25 16:07:55 -0400 2011: >> > Alvaro Herrera writes: >> > > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011: >> > >> Right. It would also increase the cognitive load on the user to have >> > >> to remember the command-line go-to-line-number switch for his editor. >> > >> So I don't particularly want to redesign this feature. However, I can >> > >> see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from >> > >> the same place that you set EDITOR, which would suggest that we allow >> > >> the value to come from an environment variable. I'm not sure whether >> > >> there is merit in allowing both that source and ~/.psqlrc, though >> > >> possibly for Windows users it might be easier if ~/.psqlrc worked. >> > >> > > If we're going to increase the number of options in .psqlrc that do not >> > > work with older psql versions, can I please have .psqlrc-MAJORVERSION or >> > > some such? Having 8.3's psql complain all the time because it doesn't >> > > understand "linestyle" is annoying. >> > >> > 1. I thought we already did have that. >> >> Oh, true, we have that, though it's not very usable because you have to >> rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when you upgrade, >> which is kinda silly. > > True. We don't add configuration changes in minor versions so having > minor-version granularity makes no sense. > > The attached patch changes this to use the _major_ version number for > psql rc files. Does this have to be backward-compatible? Should I > check for minor and major matches? That is going to be confusing to > document. Checking for a minor match and then a major match seems sensible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Alvaro Herrera wrote: > Excerpts from Tom Lane's message of mi?? may 25 16:07:55 -0400 2011: > > Alvaro Herrera writes: > > > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011: > > >> Right. It would also increase the cognitive load on the user to have > > >> to remember the command-line go-to-line-number switch for his editor. > > >> So I don't particularly want to redesign this feature. However, I can > > >> see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from > > >> the same place that you set EDITOR, which would suggest that we allow > > >> the value to come from an environment variable. I'm not sure whether > > >> there is merit in allowing both that source and ~/.psqlrc, though > > >> possibly for Windows users it might be easier if ~/.psqlrc worked. > > > > > If we're going to increase the number of options in .psqlrc that do not > > > work with older psql versions, can I please have .psqlrc-MAJORVERSION or > > > some such? Having 8.3's psql complain all the time because it doesn't > > > understand "linestyle" is annoying. > > > > 1. I thought we already did have that. > > Oh, true, we have that, though it's not very usable because you have to > rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when you upgrade, > which is kinda silly. True. We don't add configuration changes in minor versions so having minor-version granularity makes no sense. The attached patch changes this to use the _major_ version number for psql rc files. Does this have to be backward-compatible? Should I check for minor and major matches? That is going to be confusing to document. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index 662eab7..1ea728b *** a/doc/src/sgml/ref/psql-ref.sgml --- b/doc/src/sgml/ref/psql-ref.sgml *** PSQL_EDITOR_LINENUMBER_ARG='--line ' *** 3332,3338 Both the system-wide psqlrc file and the user's ~/.psqlrc file can be made version-specific by appending a dash and the PostgreSQL ! release number, for example ~/.psqlrc-&version;. A matching version-specific file will be read in preference to a non-version-specific file. --- 3332,3338 Both the system-wide psqlrc file and the user's ~/.psqlrc file can be made version-specific by appending a dash and the PostgreSQL ! major release number, for example ~/.psqlrc-9.2. A matching version-specific file will be read in preference to a non-version-specific file. diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c new file mode 100644 index 3c17eec..9670b7e *** a/src/bin/psql/startup.c --- b/src/bin/psql/startup.c *** process_psqlrc_file(char *filename) *** 600,607 #define R_OK 4 #endif ! psqlrc = pg_malloc(strlen(filename) + 1 + strlen(PG_VERSION) + 1); ! sprintf(psqlrc, "%s-%s", filename, PG_VERSION); if (access(psqlrc, R_OK) == 0) (void) process_file(psqlrc, false, false); --- 600,607 #define R_OK 4 #endif ! psqlrc = pg_malloc(strlen(filename) + 1 + strlen(PG_MAJORVERSION) + 1); ! sprintf(psqlrc, "%s-%s", filename, PG_MAJORVERSION); if (access(psqlrc, R_OK) == 0) (void) process_file(psqlrc, false, false); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Here's a patch to fix what has been discussed: * Change EDITOR_LINENUMBER_SWITCH to environment variable. * I also changed "switch" to "arg" because "switch" is a bit of a sloppy term. * So the environment variable is called PSQL_EDITOR_LINENUMBER_ARG. * Set "+" as hardcoded default value on Unix (since "vi" is the hardcoded default editor), so many users won't have to configure this at all. * I moved the documentation around a bit to centralize the editor configuration under environment variables, rather than repeating bits of it under every backslash command that invoked an editor. *** i/doc/src/sgml/ref/psql-ref.sgml --- w/doc/src/sgml/ref/psql-ref.sgml *** *** 1440,1464 testdb=> \r to cancel. - ! psql checks the environment ! variables PSQL_EDITOR, EDITOR, and ! VISUAL (in that order) for an editor to use. If ! all of them are unset, vi is used on Unix ! systems, notepad.exe on Windows systems. - ! If a line number is specified, psql will ! position the cursor on the specified line of the file or query buffer. ! This feature requires the EDITOR_LINENUMBER_SWITCH ! variable to be set, so that psql knows how ! to specify the line number to the editor. Note that if a single ! all-digits argument is given, psql assumes ! it is a line number not a file name. --- 1440,1460 \r to cancel. ! If a line number is specified, psql will ! position the cursor on the specified line of the file or query buffer. ! Note that if a single all-digits argument is given, ! psql assumes it is a line number ! not a file name. + ! See under for how to configure and ! customize your editor. + *** *** 1514,1526 Tue Oct 26 21:40:57 CEST 1999 If a line number is specified, psql will ! position the cursor on the specified line of the function body ! (note that the function body typically does not begin on the ! first line of the file). ! This feature requires the EDITOR_LINENUMBER_SWITCH ! variable to be set, so that psql knows how ! to specify the line number to the editor. --- 1510,1527 If a line number is specified, psql will ! position the cursor on the specified line of the function body. ! (Note that the function body typically does not begin on the first ! line of the file.) ! ! ! ! ! See under for how to configure and ! customize your editor. + *** *** 2599,2625 bar - EDITOR_LINENUMBER_SWITCH - - - When \edit or \ef is used with a - line number argument, this variable specifies the command-line switch - used to pass the line number to the user's editor. For editors such - as emacs or vi, you can simply set - this variable to a plus sign. Include a trailing space in the value - of the variable if there needs to be space between the switch name and - the line number. - Examples: - - - \set EDITOR_LINENUMBER_SWITCH + - \set EDITOR_LINENUMBER_SWITCH '--line ' - - - - - - ENCODING --- 2600,2605 *** *** 3167,3174 $endif ! ! Environment --- 3147,3154 ! ! Environment *** *** 3218,3225 $endif ! Editor used by the \e command. The variables ! are examined in the order listed; the first that is set is used. --- 3198,3238 ! Editor used by the \e and ! \ef commands. The variables are examined in ! the order listed; the first that is set is used. ! ! ! ! The built-in default editors are vi on Unix ! systems and notepad.exe on Windows systems. ! ! ! ! ! ! PSQL_EDITOR_LINENUMBER_ARG ! ! ! ! When \e or \ef is used ! with a line number argument, this variable specifies the ! command-line argument used to pass the starting line number to ! the user's editor. For editors such as Emacs or ! vi, this is a plus sign. Include a trailing ! space in the value of the variable if there needs to be space ! between the option name and the line number. Examples: ! ! PSQL_EDITOR_LINENUMBER_ARG='+' ! PSQL_EDITOR_LINENUMBER_ARG='--line ' ! !
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Excerpts from Tom Lane's message of mié may 25 16:07:55 -0400 2011: > Alvaro Herrera writes: > > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011: > >> Right. It would also increase the cognitive load on the user to have > >> to remember the command-line go-to-line-number switch for his editor. > >> So I don't particularly want to redesign this feature. However, I can > >> see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from > >> the same place that you set EDITOR, which would suggest that we allow > >> the value to come from an environment variable. I'm not sure whether > >> there is merit in allowing both that source and ~/.psqlrc, though > >> possibly for Windows users it might be easier if ~/.psqlrc worked. > > > If we're going to increase the number of options in .psqlrc that do not > > work with older psql versions, can I please have .psqlrc-MAJORVERSION or > > some such? Having 8.3's psql complain all the time because it doesn't > > understand "linestyle" is annoying. > > 1. I thought we already did have that. Oh, true, we have that, though it's not very usable because you have to rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when you upgrade, which is kinda silly. > 2. In any case, EDITOR_LINENUMBER_SWITCH isn't a hazard for this, > because older versions will just think it's a variable without any > special meaning. Good point. > But the real question here is whether we want to change it to be also > (or instead?) an environment variable. I vote yes. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Alvaro Herrera writes: > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011: >> Right. It would also increase the cognitive load on the user to have >> to remember the command-line go-to-line-number switch for his editor. >> So I don't particularly want to redesign this feature. However, I can >> see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from >> the same place that you set EDITOR, which would suggest that we allow >> the value to come from an environment variable. I'm not sure whether >> there is merit in allowing both that source and ~/.psqlrc, though >> possibly for Windows users it might be easier if ~/.psqlrc worked. > If we're going to increase the number of options in .psqlrc that do not > work with older psql versions, can I please have .psqlrc-MAJORVERSION or > some such? Having 8.3's psql complain all the time because it doesn't > understand "linestyle" is annoying. 1. I thought we already did have that. 2. In any case, EDITOR_LINENUMBER_SWITCH isn't a hazard for this, because older versions will just think it's a variable without any special meaning. But the real question here is whether we want to change it to be also (or instead?) an environment variable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011: > Right. It would also increase the cognitive load on the user to have > to remember the command-line go-to-line-number switch for his editor. > So I don't particularly want to redesign this feature. However, I can > see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from > the same place that you set EDITOR, which would suggest that we allow > the value to come from an environment variable. I'm not sure whether > there is merit in allowing both that source and ~/.psqlrc, though > possibly for Windows users it might be easier if ~/.psqlrc worked. If we're going to increase the number of options in .psqlrc that do not work with older psql versions, can I please have .psqlrc-MAJORVERSION or some such? Having 8.3's psql complain all the time because it doesn't understand "linestyle" is annoying. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On Tue, May 24, 2011 at 5:35 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote: >>> I noticed the 9.1 release notes claim that the new >>> EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is >>> actually a psql variable. >>> This is perhaps sort of a Freudian slip. > >> It's probably the result of drift between the original patch and what >> was eventually committed. IIRC, Pavel had it as an environment >> variable originally, but Tom and I didn't feel the feature was >> important enough to merit that treatment. > > BTW, the above is merest historical revisionism: there was never a > version of the patch that did it that way. Even if you were correct, that's a snarky way to put it, and the point is trivial anyway. But I don't think I'm imagining the getenv() call in this version of the patch: http://archives.postgresql.org/pgsql-hackers/2010-07/msg01253.php > Also, while we're on the subject, I'm not real sure why we don't allow > the code to provide a default value when EDITOR has a well-known value > like "vi" or "emacs". As long as there is a way to override that, > where's the harm in a default? Well, the question is how many people it'll help. Some people might have a full pathname, others might called it vim... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Robert Haas writes: > On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote: >> I noticed the 9.1 release notes claim that the new >> EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is >> actually a psql variable. >> This is perhaps sort of a Freudian slip. > It's probably the result of drift between the original patch and what > was eventually committed. IIRC, Pavel had it as an environment > variable originally, but Tom and I didn't feel the feature was > important enough to merit that treatment. BTW, the above is merest historical revisionism: there was never a version of the patch that did it that way. AFAICS the idea started here: http://archives.postgresql.org/pgsql-hackers/2010-08/msg00089.php to which you immediately asked whether it should be an environmental variable, and I said no on what might be considered thin grounds: http://archives.postgresql.org/pgsql-hackers/2010-08/msg00182.php I can't see any real objection other than complexity to having it look for a psql variable and then an environment variable. Or we could drop the psql variable part of that, if it seems too complicated. Also, while we're on the subject, I'm not real sure why we don't allow the code to provide a default value when EDITOR has a well-known value like "vi" or "emacs". As long as there is a way to override that, where's the harm in a default? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
Robert Haas writes: > On Tue, May 24, 2011 at 4:36 PM, Peter Eisentraut wrote: >>> That's an intriguing possibility. But part of the point of the >>> original feature was to be able to say: >>> >>> \ef somefunc 10 >>> >>> ...and end up on line 10 of somefunc, perhaps in response to an error >>> message complaining about that line. I don't think your proposal >>> would address that. >> Well, you'd write >> >> \ef somefunc +10 >> >> instead. > But that would not put you on line 10 of the function. Right. It would also increase the cognitive load on the user to have to remember the command-line go-to-line-number switch for his editor. So I don't particularly want to redesign this feature. However, I can see the possible value of letting EDITOR_LINENUMBER_SWITCH be set from the same place that you set EDITOR, which would suggest that we allow the value to come from an environment variable. I'm not sure whether there is merit in allowing both that source and ~/.psqlrc, though possibly for Windows users it might be easier if ~/.psqlrc worked. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On Tue, May 24, 2011 at 4:36 PM, Peter Eisentraut wrote: >> That's an intriguing possibility. But part of the point of the >> original feature was to be able to say: >> >> \ef somefunc 10 >> >> ...and end up on line 10 of somefunc, perhaps in response to an error >> message complaining about that line. I don't think your proposal >> would address that. > > Well, you'd write > > \ef somefunc +10 > > instead. But that would not put you on line 10 of the function. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On sön, 2011-05-22 at 06:30 +0200, Pavel Stehule wrote: > A idea with other options are > interesting. More usable can be store these option inside psql > variable (be consistent with current state). Maybe in > EDITOR_OPTIONS ? There isn't really a need for that, since if you want to pass options to your editor, you can stick them in the EDITOR variable. The idea would be more to pass options per occasion. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On lör, 2011-05-21 at 20:39 -0400, Robert Haas wrote: > On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote: > > I noticed the 9.1 release notes claim that the new > > EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is > > actually a psql variable. > It's probably the result of drift between the original patch and what > was eventually committed. IIRC, Pavel had it as an environment > variable originally, but Tom and I didn't feel the feature was > important enough to merit that treatment. I think it's not really a matter of "importance", it's a matter of making things work correctly. I have a shell configuration that sets different environment variables, including editor, depending on what directory I'm in. Now I think that all the editors in question use the + syntax, but anyone else with something like that slightly out of the ordinary would be stuck. The other problem is if I change the editor here, I have to change this other piece there. Note that you cannot even specify the editor itself in psqlrc. > > Another thought is that this whole thing could be done away with if we > > just allowed people to pass through arbitrary options to the editor, > > like > > > > \edit file.sql +50 -a -b -c > > > > For powerusers, this could have interesting possibilities. > > That's an intriguing possibility. But part of the point of the > original feature was to be able to say: > > \ef somefunc 10 > > ...and end up on line 10 of somefunc, perhaps in response to an error > message complaining about that line. I don't think your proposal > would address that. Well, you'd write \ef somefunc +10 instead. Or something else, depending on the editor, but then you'd know what to write, since under the current theory you'd have to have configured it previously. Using the "+10" syntax also looks a bit clearer, in my mind. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
2011/5/21 Peter Eisentraut : > I noticed the 9.1 release notes claim that the new > EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is > actually a psql variable. > > This is perhaps sort of a Freudian slip. Since the editor itself is > configured using an environment variable, shouldn't any configuration > about the editor also be an environment variable, so people can > configure them together? > > Another thought is that this whole thing could be done away with if we > just allowed people to pass through arbitrary options to the editor, > like > > \edit file.sql +50 -a -b -c in original patch I had to do some magic operation with line number, so I had to know, what is a line number. A idea with other options are interesting. More usable can be store these option inside psql variable (be consistent with current state). Maybe in EDITOR_OPTIONS ? With possibility to overwrite this options from metacommand \edit file.sql 10 -x -y -z Regards Pavel Stehule > > For powerusers, this could have interesting possibilities. > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] about EDITOR_LINENUMBER_SWITCH
On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote: > I noticed the 9.1 release notes claim that the new > EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is > actually a psql variable. > > This is perhaps sort of a Freudian slip. Since the editor itself is > configured using an environment variable, shouldn't any configuration > about the editor also be an environment variable, so people can > configure them together? It's probably the result of drift between the original patch and what was eventually committed. IIRC, Pavel had it as an environment variable originally, but Tom and I didn't feel the feature was important enough to merit that treatment. > Another thought is that this whole thing could be done away with if we > just allowed people to pass through arbitrary options to the editor, > like > > \edit file.sql +50 -a -b -c > > For powerusers, this could have interesting possibilities. That's an intriguing possibility. But part of the point of the original feature was to be able to say: \ef somefunc 10 ...and end up on line 10 of somefunc, perhaps in response to an error message complaining about that line. I don't think your proposal would address that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] about EDITOR_LINENUMBER_SWITCH
I noticed the 9.1 release notes claim that the new EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is actually a psql variable. This is perhaps sort of a Freudian slip. Since the editor itself is configured using an environment variable, shouldn't any configuration about the editor also be an environment variable, so people can configure them together? Another thought is that this whole thing could be done away with if we just allowed people to pass through arbitrary options to the editor, like \edit file.sql +50 -a -b -c For powerusers, this could have interesting possibilities. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers