Re: [HACKERS] psql and readline
On Wed, 8 Jan 2003, Dan Langille wrote: On 8 Jan 2003 at 12:28, Bruce Momjian wrote: Tom Lane wrote: Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? Wow, that would be a nifty trick, though they really did type \e and not the query the pulled in from the editor. What about those of us who want to use \e repeatedly? Will that be in the history buffer? The number of times I've cursed things over the years, I would have thought having the edited query in the history would be more useful than \e - the latter is only three key presses any how ;-) Peter -- Peter Mount [EMAIL PROTECTED] http://www.retep.org.uk/ Tel/Fax: +44 (0) 1622 749439 Mobile: +44 (0) 7903 155887 US Fax: 1 435 304 5165 US Voice: 1 435 304 5165 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] psql and readline
On 9 Jan 2003 at 9:15, Robert Treat wrote: On Thu, 2003-01-09 at 08:45, Peter Mount wrote: On Wed, 8 Jan 2003, Dan Langille wrote: On 8 Jan 2003 at 12:28, Bruce Momjian wrote: Tom Lane wrote: Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? Wow, that would be a nifty trick, though they really did type \e and not the query the pulled in from the editor. What about those of us who want to use \e repeatedly? Will that be in the history buffer? The number of times I've cursed things over the years, I would have thought having the edited query in the history would be more useful than \e - the latter is only three key presses any how ;-) Or if the query could be appended after the \e, it would only be a quick double-up to get back to the \e. As this is changing existing behaviour, I think adding an optional switch to revert to the old behaviour is a good idea. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] clock sync
How do I know the clock on the machine you're running on will be set to the same time as the clock on the database? how postgre handle this internal? thanks. johnl ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql and readline
Dan Langille wrote: snip As this is changing existing behaviour, I think adding an optional switch to revert to the old behaviour is a good idea. Two thoughts: a) Is it possible to change the behavior of the history as we're discussing? Haven't heard Peter's response to this. b) Do we really want to go to the effort of adding a switch to revert to previous behaviour for something like this? It's almost definitely a win to have \e commands appear in the history, and seems a bit to trivial for adding switches for. ? Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql and readline
Justin Clift wrote: b) Do we really want to go to the effort of adding a switch to revert to previous behaviour for something like this? It's almost definitely a win to have \e commands appear in the history, and seems a bit to trivial for adding switches for. Bad wording there... \e commands is meant to mean commands created through using \e -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Tom, Tom Lane writes: Lee Kindness [EMAIL PROTECTED] writes: + #define _THREAD_SAFE + #define _REENTRANT + #define _POSIX_PTHREAD_SEMANTICS What is this stuff, and why isn't it wrapped in any sort of platform-specific test? If it's needed, why is it in only one .c file? It's actually in libpq-int.h too... The correct way for this is to compile with the compilers specific thread flags, however the downside to this has already been discussed. Depending on the system one, or a combination of those flags will turn on some magic such as errno being a function call rather than a global variable. This is needed to make the library thread safe. On a second look libpq-int.h isn't the best place for this (hence it also appears in one of the C files), it needs to be done in each C file before any of the system headers are included - a libpq-threads.h header? Would this be ok? Do do things 100% right we'd need to detect compiler thread flags and compile with them... Also, haven't you broken SOCK_STRERROR for the Windows case? Sorry, I seem to have forgotton to update the prototype in win32.h to match the updated function. Updated diff attached (and online). Lee. diffs-libpq.txt Description: Binary data ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] psql and readline
On Thu, 09 Jan 2003 10:13:14 EST, the world broke into rejoicing as Bruce Momjian [EMAIL PROTECTED] said: Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. i.e. one up arrow get the previous \e, and a second up arrow would bring up the command that was worked upon. Makese sense. However, it still has the shock factor of displaying a huge query, which is usually what is involved when using the editor. I don't feel strongly either way --- I am just pointing out the issue. There's a surprise available in both directions. If the previous command was use external editor on query, then it seems unreasonable to forcibly expand that out. If I edited the query, it's more than likely that I'd like to edit it again. But I'd like to have a way to expand the query so that I /can/ see it in full form. It would be unfortunate for the /only/ way to get at the query would be to \e it. Perhaps the answer is to have some form of \expand directive that replaces itself with the query's contents, or, better still, which doesn't actually /execute/ the query, but rather pulls in the query from outside and pushes it into the command line. The /next/ time you hit enter, the query will get executed. -- output = reverse(moc.enworbbc@ enworbbc) http://cbbrowne.com/info/linux.html Eagles may soar, free and proud, but weasels never get sucked into jet engines. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] clock sync
On Thu, 09 Jan 2003 08:39:33 CST, the world broke into rejoicing as John Liu [EMAIL PROTECTED] said: How do I know the clock on the machine you're running on will be set to the same time as the clock on the database? how postgre handle this internal? You'll know because you already run NTP on all your servers to make sure that they are synchronizing times, right? PostgreSQL doesn't include time synchronization software because NTP does that perfectly well, just as it doesn't include a job scheduler because cron does that perfectly well. ... And if your machines have substantially different times, different sorts of issues will emerge depending on what you're doing. - If the client sends over literal current time stamps based on what time it thinks it is, that may differ from what time the server thinks it is. - If you do that, and then try looking in PostgreSQL logs, based on the client's timestamps, you'll look at the wrong times, and get confused. - If the client passes in things that select now(), timestamps will be returned based on when the /server/ thinks it is. Which should leave the database consistent, but which might confuse the client if it has logic that processes that time, and gets deranged because now() differs massively from what time it thinks it is. The case where you'll get /badly/ bitten is if you're trying to do replication with servers that have substantially differing ideas as to what time it is. But what you /should/ do is run NTP on all your machines, thus getting rid of the problem. http://www.ntp.org/ -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://www3.sympatico.ca/cbbrowne/ntp.html Rules of the Evil Overlord #30. All bumbling conjurers, clumsy squires, no-talent bards, and cowardly thieves in the land will be preemptively put to death. My foes will surely give up and abandon their quest if they have no source of comic relief. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Guys, just posted patches for libpq to address thread-safe issues. Now uses strerror_r(), gethostbyname_r(), getpwuid_r() and crypt_r() where available. Passes all tests on Linux and Solaris. Any comments let me know - my first major(ish) outing in the PostgreSQL source, in particular I'm not use in the configure stuff is 100% right... Patches also at: http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gz http://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz Thanks, Lee. Lee Kindness writes: Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] writes: We have definatly had requests for improved thread-safeness for libpq and ecpg in the past, so whatever you can do would be a help. We say libpq is thread-safe, but specifically mention the non-threadsafe calls in the libpq documentation, or at least we should. We do: http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html But Lee's point about depending on possibly-unsafe libc routines is a good one. I don't think anyone's gone through the code with an eye to that. Right, so a reasonable angle for me to take is to go through the libpq source looking for potential problem areas and use of known bad functions. I can add autoconf checks for the replacement *_r() functions, and use these in place of the traditional ones where available. If any function is found to be not thread-safe and cannot be made so using standard library calls then it needs to be documented as such both in the source and the aforementioned documentation. This approach avoids any thread library dependencies and documents the current state of play WRT thread safety (i.e it's a good, and needed, basis for any later work). ECPG is a separate issue, and best handled as such (it will need thread calls). I'll post a patch for it at a later date so the changes are available to anyone who wants to play with ECPG and threads. Ta, Lee. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and readline
On Thu, 2003-01-09 at 08:45, Peter Mount wrote: On Wed, 8 Jan 2003, Dan Langille wrote: On 8 Jan 2003 at 12:28, Bruce Momjian wrote: Tom Lane wrote: Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? Wow, that would be a nifty trick, though they really did type \e and not the query the pulled in from the editor. What about those of us who want to use \e repeatedly? Will that be in the history buffer? The number of times I've cursed things over the years, I would have thought having the edited query in the history would be more useful than \e - the latter is only three key presses any how ;-) Or if the query could be appended after the \e, it would only be a quick double-up to get back to the \e. Robert Treat ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql and readline
resent with my real mail address... On 9 Jan 2003 at 13:45, Peter Mount wrote: On Wed, 8 Jan 2003, Dan Langille wrote: On 8 Jan 2003 at 12:28, Bruce Momjian wrote: Tom Lane wrote: Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? Wow, that would be a nifty trick, though they really did type \e and not the query the pulled in from the editor. What about those of us who want to use \e repeatedly? Will that be in the history buffer? The number of times I've cursed things over the years, I would have thought having the edited query in the history would be more useful than \e - the latter is only three key presses any how ;-) It is easier to edit things within an editor than within the command line, especially if using very long complex statements involving 8 or 9 tables and nested/outer JOINS. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and readline
Justin Clift wrote: Dan Langille wrote: snip As this is changing existing behaviour, I think adding an optional switch to revert to the old behaviour is a good idea. Two thoughts: a) Is it possible to change the behavior of the history as we're discussing? Haven't heard Peter's response to this. b) Do we really want to go to the effort of adding a switch to revert to previous behaviour for something like this? It's almost definitely a win to have \e commands appear in the history, and seems a bit to trivial for adding switches for. Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
On Wed, 2003-01-08 at 15:30, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... You could use ledit, piped with psql works great. I use it with sqlplus from Oracle too, adds me readline functions sqlplus doesnt have: Under Debian GNU/Linux: $ apt-cache search ledit ledit - A line editor for interactive programs. It has some OpenCAML dependencies, beware. After: $ ledit | psql yourdatabase ...my 2 cents -- Jean-Paul ARGUDO DBA PostgreSQL, MySQL, Oracle, Ingres Membre de l'April http://www.april.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] EXPLAIN EXECUTE
Peter Eisentraut [EMAIL PROTECTED] writes: I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE. Might be handy to have. Yeah, that was on my to-fix list also. There is more reason to have this than just completeness: as things stand, EXPLAIN cannot teach you anything about what the planner does with parameterized queries --- which arise not only in PREPARE, but in SQL and plpgsql functions. EXPLAIN EXECUTE would make it possible to look at parameterized plans. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dollar in identifiers
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:55 PM To: Peter Eisentraut Cc: Tom Lane; Jan Wieck; PostgreSQL HACKERS Subject: Re: [HACKERS] Dollar in identifiers Peter Eisentraut wrote: Tom Lane writes: Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. I agree with the first one, but does it have to imply the second? I believe he wanted the second because Oracle supports it, and some Oracle apps use that feature. I think in the old days, before underscore, Oracle used $ for space (double yuck). There are a few others also that use dollar signs such as DEC Rdb, Interbase/Firebird, etc. as well. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dollar in identifiers
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:27 PM To: Jan Wieck Cc: Bruce Momjian; Peter Eisentraut; PostgreSQL HACKERS Subject: Re: [HACKERS] Dollar in identifiers Jan Wieck [EMAIL PROTECTED] writes: The problem is, discouraged or not, if there's a slot people will stick something into ... meaning if it accepts a dollar, to hell with vendor recommendations! I'm confused; are you voting against allowing dollar in identifiers? I thought it was you that proposed allowing it in the first place ... Suggestion: Allow them, but issue a warning on schema creation that uses dollars in identifiers. NOTICE: Dollar signs($) in identifiers are not allowed by ANSI/ISO SQL Something like that. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Prepared statements question
Hi, With prepared statements being all well and good, how do I know if the query has not yet been prepared in the backend? Or is this simply a situation where I can't win? eg. Say I have a web page that does a humungous query. I would like to have that query prepared, say, for speed. However, I can't tell if that backend has had that query prepared or not. Is there any way around this? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Prepared statements question
I guess I should just use a stored procedure... Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Kings-Lynne Sent: Friday, 10 January 2003 11:48 AM To: Hackers Subject: [HACKERS] Prepared statements question Hi, With prepared statements being all well and good, how do I know if the query has not yet been prepared in the backend? Or is this simply a situation where I can't win? eg. Say I have a web page that does a humungous query. I would like to have that query prepared, say, for speed. However, I can't tell if that backend has had that query prepared or not. Is there any way around this? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IPv6 patch
Peter Eisentraut wrote: Bruce Momjian writes: OK, Peter, to keep you and everyone happy, what changes are your proposing to the existing code, if any. The only current behavior is printing an IPv6 failure for IPv6-enabled backend in the server logs. Just bind to all addresses you can find, IPv4 or IPv6. And leave pg_hba.conf alone. OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if the OS doesn't support it. How do others feel about that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Dollar in identifiers
Peter Eisentraut wrote: Tom Lane writes: Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. I agree with the first one, but does it have to imply the second? I believe he wanted the second because Oracle supports it, and some Oracle apps use that feature. I think in the old days, before underscore, Oracle used $ for space (double yuck). -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql and readline
Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. i.e. one up arrow get the previous \e, and a second up arrow would bring up the command that was worked upon. ? Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql and readline
Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. i.e. one up arrow get the previous \e, and a second up arrow would bring up the command that was worked upon. Makese sense. However, it still has the shock factor of displaying a huge query, which is usually what is involved when using the editor. I don't feel strongly either way --- I am just pointing out the issue. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] unsubscrieb
unsubsriebMSN 8: advanced junk mail protection and 2 months FREE*
Re: [HACKERS] psql and readline
On 9 Jan 2003 at 10:13, Bruce Momjian wrote: Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. i.e. one up arrow get the previous \e, and a second up arrow would bring up the command that was worked upon. Makese sense. However, it still has the shock factor of displaying a huge query, which is usually what is involved when using the editor. Which is a good indicator that a way to turn it off is a good idea. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql and readline
On Thu, 2003-01-09 at 10:12, Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. We could always create a new command that edits a query buffer rather than file \e FILENAME \E QUERY BUFFER So, history of: \E SELECT ... Selecting this would fire off an editor based on the query to the right of the command, much as \e FILENAME opens an editor based on the file to the right of the command. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] psql and readline
On 9 Jan 2003, Rod Taylor wrote: On Thu, 2003-01-09 at 10:12, Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. We could always create a new command that edits a query buffer rather than file \e FILENAME \E QUERY BUFFER So, history of: \E SELECT ... Selecting this would fire off an editor based on the query to the right of the command, much as \e FILENAME opens an editor based on the file to the right of the command. That's a possible one, but the only problem I can see is if the user uses \e on it's own (ie not read in a file). Do we then place just \e or \E QUERY BUFFER into the history? Peter -- Peter Mount [EMAIL PROTECTED] http://www.retep.org.uk/ Tel/Fax: +44 (0) 1622 749439 Mobile: +44 (0) 7903 155887 US Fax: 1 435 304 5165 US Voice: 1 435 304 5165 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] psql and readline
On Thu, 2003-01-09 at 10:42, Peter Mount wrote: On 9 Jan 2003, Rod Taylor wrote: On Thu, 2003-01-09 at 10:12, Justin Clift wrote: Bruce Momjian wrote: snip Let's suppose I am writing a query, and then I do \e to edit the query, and I exit the editor and return to psql. Suppose I decide I want to reedit, so I up arrow. I would expect to get \e, not the query I just edited, no? Wouldn't it depend on how this gets implemented? Maybe least negative impact approach (suggested already): If the large command that was edited is put in the command history before the \e, then both are available and there is no big change from expected behaviour. We could always create a new command that edits a query buffer rather than file \e FILENAME \E QUERY BUFFER So, history of: \E SELECT ... Selecting this would fire off an editor based on the query to the right of the command, much as \e FILENAME opens an editor based on the file to the right of the command. That's a possible one, but the only problem I can see is if the user uses \e on it's own (ie not read in a file). Do we then place just \e or \E QUERY BUFFER into the history? I'd tend to switch it to store \E QUERY BUFFER in the history, and possibly remove the ability to use \e by itself -- or make \E FILENAME and \e QUERY BUFFER. Since the use of \e isn't likely to be used in a programmatic (automated) way, but only by users who could quickly figure it out. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] psql and readline
Rod Taylor wrote: I'd tend to switch it to store \E QUERY BUFFER in the history, and possibly remove the ability to use \e by itself -- or make \E FILENAME and \e QUERY BUFFER. Since the use of \e isn't likely to be used in a programmatic (automated) way, but only by users who could quickly figure it out. I don't think it makes sense to remove \e just to add history functionality. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql and readline
Bruce Momjian [EMAIL PROTECTED] writes: Rod Taylor wrote: Since the use of \e isn't likely to be used in a programmatic (automated) way, but only by users who could quickly figure it out. I don't think it makes sense to remove \e just to add history functionality. Indeed, that would defeat the purpose completely, wouldn't it? If you are using the \e file form then the contents of the file already provide history, of a sort (at least, you can get back the immediately preceding version of the query when you edit it). The case I find interesting is where you're using plain \e to re-edit a query interactively. If this query never gets into the history buffer then you're lost: you won't be able to pull it back for re-editing a second time. Perhaps more to the point: without the \e form, \e does not offer a solution to the original poster's request, and so we're back to square one. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
Hi guys, As a curiosity thought, would it be possible to do something like: \ep Where this tells psql to get the query in the history prior to the \e, and edit it interactively? :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] psql and readline
On Thu, 9 Jan 2003, Bruce Momjian wrote: Rod Taylor wrote: I'd tend to switch it to store \E QUERY BUFFER in the history, and possibly remove the ability to use \e by itself -- or make \E FILENAME and \e QUERY BUFFER. Since the use of \e isn't likely to be used in a programmatic (automated) way, but only by users who could quickly figure it out. I don't think it makes sense to remove \e just to add history functionality. I agree. Also more people would type \e than they would \E. Also they are used to having \e available. Adding the functionality to the history is useful, but we shouldn't change things too much. I currently think that if \e is typed on it's own, then \E QUERY BUFFER goes into the history. Keep the existing behaviour of \e FILENAME the same. I'd doubt that a user would type \E QUERY BUFFER themselves often (if at all). Peter -- Peter Mount [EMAIL PROTECTED] http://www.retep.org.uk/ Tel/Fax: +44 (0) 1622 749439 Mobile: +44 (0) 7903 155887 US Fax: 1 435 304 5165 US Voice: 1 435 304 5165 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Dollar in identifiers
Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. (It'd have to be non-first to avoid ambiguity with parameter symbols $nnn.) See, eg, http://archives.postgresql.org/pgsql-hackers/2001-08/msg00629.php That discussion petered out without any definite consensus being reached, but I think it's time to reconsider the idea. We're getting flak about x$n being parsed as x $ n rather than x $n (see current thread in pgsql-sql). While this has always been a hazard for SQL and plpgsql function writers, it is now also a hazard in direct SQL, if you use PREPAREd queries. So I think the importance of avoiding such problems has moved up a notch as of 7.3. So, I'd like to put that proposal back on the table. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dollar in identifiers
I agree. I think $ is too special to be mixed in with operators. It is just used too frequently for variables. --- Tom Lane wrote: Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. (It'd have to be non-first to avoid ambiguity with parameter symbols $nnn.) See, eg, http://archives.postgresql.org/pgsql-hackers/2001-08/msg00629.php That discussion petered out without any definite consensus being reached, but I think it's time to reconsider the idea. We're getting flak about x$n being parsed as x $ n rather than x $n (see current thread in pgsql-sql). While this has always been a hazard for SQL and plpgsql function writers, it is now also a hazard in direct SQL, if you use PREPAREd queries. So I think the importance of avoiding such problems has moved up a notch as of 7.3. So, I'd like to put that proposal back on the table. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Execute command type
Peter Eisentraut [EMAIL PROTECTED] writes: Is there a time when QueryDesc-operation is not equal to QueryDesc-parsetree-cmdType? I don't believe so. Not sure why the code bothers to store the redundant field. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dollar in identifiers
Jan Wieck [EMAIL PROTECTED] writes: The problem is, discouraged or not, if there's a slot people will stick something into ... meaning if it accepts a dollar, to hell with vendor recommendations! I'm confused; are you voting against allowing dollar in identifiers? I thought it was you that proposed allowing it in the first place ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql and readline
On Thu, Jan 09, 2003 at 10:49:33PM +0100, Peter Eisentraut wrote: Christopher Kings-Lynne writes: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? There is nothing technical that should prevent you from implementing it. But you need to come up with a reasonable system to keep the history straight if meta commands are mixed with multiline commands, such as select * \x from foo; Peter, what do you think about pushing the query buffer onto the history stack at execution time, any time it's a multiline query? That way, after the above sequence, you'd have: (1) select * (2) \x (3) from foo; (4) select * from foo; Yeah, this wastes a history slot, but it does solve the problem. It's also dead simple to code. ;-) BTW, the behavior in bash for multiline interactive entered commands is to concatenate them into a single line and dump them in the history, replacing the individual parts. The individual parts are in the history while you're at the secondary prompt, then go away after execution. In psql, we'd probably just lose interstitial metacommands. Ross ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Dollar in identifiers
Tom Lane writes: Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. I agree with the first one, but does it have to imply the second? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dollar in identifiers
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: The problem is, discouraged or not, if there's a slot people will stick something into ... meaning if it accepts a dollar, to hell with vendor recommendations! I'm confused; are you voting against allowing dollar in identifiers? I thought it was you that proposed allowing it in the first place ... You are, I don't and I was, indeed. Remove Dollar from the operators and allow it as non-first identifier char. Please :-) Jan regards, tom lane -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dollar in identifiers
Bruce Momjian wrote: Peter Eisentraut wrote: Tom Lane writes: Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. I agree with the first one, but does it have to imply the second? I believe he wanted the second because Oracle supports it, and some Oracle apps use that feature. I think in the old days, before underscore, Oracle used $ for space (double yuck). Dollar is not allowed as per SQL spec. And I think Oracle discouraged people from using it, but used it in their own stuff. Good way to avoid any possible conflicts and I would've liked our version of it to be pg$ instead of pg_ ... I think that's a bit too much to ask for, is it? The problem is, discouraged or not, if there's a slot people will stick something into ... meaning if it accepts a dollar, to hell with vendor recommendations! Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Dollar in identifiers
Change it - but just put it in the release notes :) Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane Sent: Friday, 10 January 2003 1:10 AM To: Jan Wieck; Peter Eisentraut Cc: PostgreSQL HACKERS Subject: Re: [HACKERS] Dollar in identifiers Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. (It'd have to be non-first to avoid ambiguity with parameter symbols $nnn.) See, eg, http://archives.postgresql.org/pgsql-hackers/2001-08/msg00629.php That discussion petered out without any definite consensus being reached, but I think it's time to reconsider the idea. We're getting flak about x$n being parsed as x $ n rather than x $n (see current thread in pgsql-sql). While this has always been a hazard for SQL and plpgsql function writers, it is now also a hazard in direct SQL, if you use PREPAREd queries. So I think the importance of avoiding such problems has moved up a notch as of 7.3. So, I'd like to put that proposal back on the table. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] EXPLAIN EXECUTE
On Thu, 2003-01-09 at 16:53, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE. Might be handy to have. Yeah, that was on my to-fix list also. Heh, I too was planning to implement this. Would you like to take a crack it at, or should I? Cheers, Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] EXPLAIN EXECUTE
Neil Conway [EMAIL PROTECTED] writes: On Thu, 2003-01-09 at 16:53, Tom Lane wrote: Yeah, that was on my to-fix list also. Heh, I too was planning to implement this. Would you like to take a crack it at, or should I? Go for it... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] psql and readline
On Thu, 9 Jan 2003, Peter Eisentraut wrote: Tom Lane writes: The case I find interesting is where you're using plain \e to re-edit a query interactively. If this query never gets into the history buffer then you're lost: you won't be able to pull it back for re-editing a second time. If you call \e again immediately then you edit the previous command. Yes, but it's not always the last command you want :-( Peter -- Peter Mount [EMAIL PROTECTED] http://www.retep.org.uk/ Tel/Fax: +44 (0) 1622 749439 Mobile: +44 (0) 7903 155887 US Fax: 1 435 304 5165 US Voice: 1 435 304 5165 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql and readline
On Fri, Jan 10, 2003 at 07:15:34AM +, Peter Mount wrote: On Thu, 9 Jan 2003, Peter Eisentraut wrote: Tom Lane writes: The case I find interesting is where you're using plain \e to re-edit a query interactively. If this query never gets into the history buffer then you're lost: you won't be able to pull it back for re-editing a second time. If you call \e again immediately then you edit the previous command. Yes, but it's not always the last command you want :-( I already posted a one-line patch to implement this, but it doesn't seem to hve come through to the list. Here it is inline, instead of as an attachment: Index: src/bin/psql/command.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v retrieving revision 1.84 diff -u -r1.84 command.c --- src/bin/psql/command.c 2002/10/23 19:23:56 1.84 +++ src/bin/psql/command.c 2003/01/09 22:18:49 @@ -1639,6 +1639,7 @@ error = true; } + replace_history_entry(where_history(),query_buf-data,NULL); fclose(stream); } Ross ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] IPv6 patch
Bruce Momjian writes: OK, Peter, to keep you and everyone happy, what changes are your proposing to the existing code, if any. The only current behavior is printing an IPv6 failure for IPv6-enabled backend in the server logs. Just bind to all addresses you can find, IPv4 or IPv6. And leave pg_hba.conf alone. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dollar in identifiers
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Quite awhile back, we had a discussion about removing $ from the set of allowed characters in operator names, and instead allowing it as a non-first character in identifiers. I agree with the first one, but does it have to imply the second? It does not have to, but then we'd only be using $ for parameters, which seems like we're not getting our money's worth out of the character (pun intended). Also, the original point of that discussion was that Oracle allows $ in identifiers, and people wanted to port Oracle code without having to rename their stuff. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql and readline
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: The case I find interesting is where you're using plain \e to re-edit a query interactively. If this query never gets into the history buffer then you're lost: you won't be able to pull it back for re-editing a second time. If you call \e again immediately then you edit the previous command. But it'd be nice to have some *history*, ie be able to pull back older commands. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and readline
Christopher Kings-Lynne writes: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? There is nothing technical that should prevent you from implementing it. But you need to come up with a reasonable system to keep the history straight if meta commands are mixed with multiline commands, such as select * \x from foo; -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql and readline
Tom Lane writes: The case I find interesting is where you're using plain \e to re-edit a query interactively. If this query never gets into the history buffer then you're lost: you won't be able to pull it back for re-editing a second time. If you call \e again immediately then you edit the previous command. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] EXPLAIN EXECUTE
I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE. Might be handy to have. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
