Re: [HACKERS] psql: Don't close stdin, don't leak file descriptor with ON_ERROR_STOP

2010-10-26 Thread Robert Haas
On Wed, Oct 20, 2010 at 5:54 PM, Marti Raudsepp ma...@juffo.org wrote: Here's the second patch from my coccicheck run. Originally it flagged the fact that the opened file in psql's process_file() wasn't being closed in the ON_ERROR_STOP path, but there seem to be two more unintended behaviors

Re: [HACKERS] psql autocompletion for \z and \dg

2010-10-21 Thread Robert Haas
On Wed, Oct 20, 2010 at 10:56 PM, Josh Kupershmidt schmi...@gmail.com wrote: It looks like psql's tab completion for the \z and \dg commands in psql are missing. I couldn't see a reason for this, so attached patch fixes. Also, this patch proposes to change psql's \? help text to say that \dg

Re: [HACKERS] psql autocompletion for \z and \dg

2010-10-21 Thread Josh Kupershmidt
On Thu, Oct 21, 2010 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote: Please add this in the usual spot: https://commitfest.postgresql.org/action/commitfest_view/open Aye sir, added. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] psql \timing output supressed in quiet mode

2010-07-26 Thread Kevin Grittner
Peter Eisentraut pete...@gmx.net wrote: In psql's quiet mode, the output of the \timing option is suppressed, except in the \copy command. That inconsistency should be fixed in any case. It seems to me that if I explicitly turn on timing, then that should be unaffected by the quiet mode.

Re: [HACKERS] psql \timing output supressed in quiet mode

2010-07-25 Thread Robert Haas
On Sun, Jul 25, 2010 at 5:58 AM, Peter Eisentraut pete...@gmx.net wrote: In psql's quiet mode, the output of the \timing option is suppressed, except in the \copy command.  That inconsistency should be fixed in any case.  It seems to me that if I explicitly turn on timing, then that should be

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-23 Thread Robert Haas
On Wed, Jul 21, 2010 at 11:13 PM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Jul 22, 2010 at 11:57 AM, Robert Haas robertmh...@gmail.com wrote: Should we be using is_absolute_path() here instead, as libpq does? Yes. The attached patch does that. On Wed, Jul 21, 2010 at 10:09 PM, David

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-21 Thread Robert Haas
On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: OK, committed. When I specify the path of the directory for the Unix-domain socket as the host, \conninfo doesn't mention that this connection

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-21 Thread Fujii Masao
On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: OK, committed. When I specify the path of the directory for the

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-21 Thread David Christensen
On Jul 21, 2010, at 8:48 PM, Fujii Masao wrote: On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: OK, committed.

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-21 Thread Robert Haas
On Wed, Jul 21, 2010 at 9:48 PM, Fujii Masao masao.fu...@gmail.com wrote: On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-21 Thread Robert Haas
On Wed, Jul 21, 2010 at 10:09 PM, David Christensen da...@endpoint.com wrote: On Jul 21, 2010, at 8:48 PM, Fujii Masao wrote: On Wed, Jul 21, 2010 at 7:29 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jul 21, 2010 at 1:07 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jul 20,

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-21 Thread Fujii Masao
On Thu, Jul 22, 2010 at 11:57 AM, Robert Haas robertmh...@gmail.com wrote: Should we be using is_absolute_path() here instead, as libpq does? Yes. The attached patch does that. On Wed, Jul 21, 2010 at 10:09 PM, David Christensen da...@endpoint.com wrote: If we print the local socket when

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-20 Thread Robert Haas
On Tue, Jul 20, 2010 at 12:16 AM, David Christensen da...@endpoint.com wrote: On Jul 19, 2010, at 11:10 PM, Robert Haas wrote: On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Jul 20, 2010 at 12:02 AM, David Christensen da...@endpoint.com wrote: I would

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-20 Thread Fujii Masao
On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote: OK, committed. When I specify the path of the directory for the Unix-domain socket as the host, \conninfo doesn't mention that this connection is based on the Unix-domain socket. Is this intentional? $ psql -h/tmp

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread Robert Haas
On Sun, Jul 18, 2010 at 2:00 PM, David Christensen da...@endpoint.com wrote: Updated the commitfest entry with the patch, updated the title to reflect the actual name of the command, and marked as ready for committer. I took a look at this patch. One problem is that it doesn't handle the case

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread David Christensen
On Jul 19, 2010, at 10:34 PM, Robert Haas wrote: On Sun, Jul 18, 2010 at 2:00 PM, David Christensen da...@endpoint.com wrote: Updated the commitfest entry with the patch, updated the title to reflect the actual name of the command, and marked as ready for committer. I took a look at this

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread Robert Haas
On Mon, Jul 19, 2010 at 11:41 PM, David Christensen da...@endpoint.com wrote: I took a look at this patch.  One problem is that it doesn't handle the case where there is no database connection (for example, shut down the database with pg_ctl, then do select 1, then do \conninfo).  I've fixed

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread David Christensen
I would propose to print instead: You are connected to database rhaas via local socket as user rhaas. One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple ones running on different local sockets, so maybe either the port or the

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread Robert Haas
On Tue, Jul 20, 2010 at 12:02 AM, David Christensen da...@endpoint.com wrote: I would propose to print instead: You are connected to database rhaas via local socket as user rhaas. One minor quibble here; you lose the ability to see which pg instance you're running on if there are multiple

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread Robert Haas
On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Jul 20, 2010 at 12:02 AM, David Christensen da...@endpoint.com wrote: I would propose to print instead: You are connected to database rhaas via local socket as user rhaas. One minor quibble here; you lose

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

2010-07-19 Thread David Christensen
On Jul 19, 2010, at 11:10 PM, Robert Haas wrote: On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Jul 20, 2010 at 12:02 AM, David Christensen da...@endpoint.com wrote: I would propose to print instead: You are connected to database rhaas via local socket

Re: [HACKERS] psql auto-completion for multiple where clauses

2010-07-16 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Someone highlighed on IRC that after the first WHERE clause, autocomplete no longer works. ... SELECT * FROM tab_completion WHERE id = 2 AND stabtab ... Is there any chance of improving this so it would work for more than 1 WHERE clause?

Re: [HACKERS] psql auto-completion for multiple where clauses

2010-07-16 Thread Thom Brown
On 16 July 2010 16:04, Greg Sabino Mullane g...@turnstep.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Someone highlighed on IRC that after the first WHERE clause, autocomplete no longer works. ... SELECT * FROM tab_completion WHERE id = 2 AND stabtab ... Is there any

Re: [HACKERS] psql auto-completion for multiple where clauses

2010-07-16 Thread Tom Lane
Greg Sabino Mullane g...@turnstep.com writes: No: there is only a small number of words that we go back through, so the above will not work as we cannot get back to the name of the table from the right side of the AND. The way to fix that is to redesign our tab-completion system such that

Re: [HACKERS] psql: ON_ERROR_STOP command-line flag for scripts

2010-06-07 Thread Stephen Frost
* Mike Toews (mwto...@gmail.com) wrote: I know I can either embed a non-SQL command in the SQL file or add --set ON_ERROR_STOP =1 to the command arguments, however I'd like a simpler command interface (just like there is -q / --quiet for QUIET). Could I suggest a new command-line option -r /

Re: [HACKERS] psql \? \daS

2010-05-26 Thread Robert Haas
On Wed, May 26, 2010 at 1:59 PM, Stephen Frost sfr...@snowman.net wrote:  Noticed this while playing around with psql regression tests. Good catch. It looks like the + option doesn't actually do anything for \da, though, so I'm inclined to just write \da[S] rather than \da[S+] (see: \dl, \dC).

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

2010-04-25 Thread Bernd Helmle
--On 23. April 2010 14:34:45 -0700 Steve Atkins st...@blighty.com wrote: Or more generally an ability to set aliases via .psqlrc similar to \set, maybe? \alias \d- = \d \alias \d = \d+ You mean something like this? http://archives.postgresql.org/pgsql-patches/2008-04/msg5.php --

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

2010-04-24 Thread Terry Brown
On Fri, 23 Apr 2010 14:28:38 -0400 Tom Lane t...@sss.pgh.pa.us wrote: If we were to do something like that, it would certainly have to affect every \d variant that has a + option. Which is probably not a very good idea --- in many cases that's a very expensive/verbose option. I can't get

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

2010-04-24 Thread Terry Brown
On Fri, 23 Apr 2010 14:34:45 -0700 Steve Atkins st...@blighty.com wrote: Maybe a configuration variable along the lines of 'always_show_comments' would be a better design. Or more generally an ability to set aliases via .psqlrc similar to \set, maybe? \alias \d- = \d \alias \d =

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

2010-04-23 Thread Ross J. Reedstrom
On Fri, Apr 23, 2010 at 10:58:40AM -0500, Terry Brown wrote: I asked on IRC if there was any way to make \d behave like \d+ by default, and davidfetter said no but suggest it here. endpoint_david pointed out you could use \d- to get the old behavior if you wanted to temporarily negate the

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

2010-04-23 Thread Tom Lane
Ross J. Reedstrom reeds...@rice.edu writes: On Fri, Apr 23, 2010 at 10:58:40AM -0500, Terry Brown wrote: So the proposal would be: \d+ does as it has always done, no change \d- (new) always behaves like 'old' \d \d acts as 'old' \d or as \d+, depending on the setting of

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

2010-04-23 Thread Steve Atkins
On Apr 23, 2010, at 11:28 AM, Tom Lane wrote: Ross J. Reedstrom reeds...@rice.edu writes: On Fri, Apr 23, 2010 at 10:58:40AM -0500, Terry Brown wrote: So the proposal would be: \d+ does as it has always done, no change \d- (new) always behaves like 'old' \d \d acts as 'old' \d or as

Re: [HACKERS] psql: edit function, show function commands patch

2010-03-31 Thread Bruce Momjian
I have added this to the next commit-fest. --- Pavel Stehule wrote: Hello this simple patch allow to specify cursor row when some function is opened in editor. \e aaa.txt \a aaa.txt 3 ... move cursor on 3nd line of

Re: [HACKERS] psql: edit function, show function commands patch

2010-03-31 Thread Pavel Stehule
2010/4/1 Bruce Momjian br...@momjian.us: I have added this to the next commit-fest. thank you Pavel --- Pavel Stehule wrote: Hello this simple patch allow to specify cursor row when some function is opened in

Re: [HACKERS] psql with GSS can crash

2010-03-08 Thread Magnus Hagander
2010/3/7 Zdenek Kotala zdenek.kot...@sun.com: Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100: 2010/3/1 Zdenek Kotala zdenek.kot...@sun.com: Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100: On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote: Hi all,

Re: [HACKERS] psql with GSS can crash

2010-03-07 Thread Zdenek Kotala
Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100: 2010/3/1 Zdenek Kotala zdenek.kot...@sun.com: Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100: On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote: Hi all, I got following stack: fd7ffed14b70

Re: [HACKERS] psql with Function Type in \df

2010-03-02 Thread Bruce Momjian
David Fetter wrote: On Thu, Feb 25, 2010 at 07:20:58PM -0500, Bruce Momjian wrote: Did we ever get tab completion support for these backslash commands? Nope :/ Not sure if I'll be able to get to it this week, either. What is the TODO description then? -- Bruce Momjian

Re: [HACKERS] psql with GSS can crash

2010-03-01 Thread Zdenek Kotala
Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100: On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote: Hi all, I got following stack: fd7ffed14b70 strlen () + 40 fd7ffed71665 snprintf () + e5 fd7fff36d088 pg_GSS_startup () + 88

Re: [HACKERS] psql with GSS can crash

2010-03-01 Thread Magnus Hagander
2010/3/1 Zdenek Kotala zdenek.kot...@sun.com: Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100: On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote: Hi all, I got following stack:  fd7ffed14b70 strlen () + 40  fd7ffed71665 snprintf () + e5  

Re: [HACKERS] psql with Function Type in \df

2010-02-28 Thread David Fetter
On Thu, Feb 25, 2010 at 07:20:58PM -0500, Bruce Momjian wrote: Did we ever get tab completion support for these backslash commands? Nope :/ Not sure if I'll be able to get to it this week, either. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778

Re: [HACKERS] psql with GSS can crash

2010-02-25 Thread Magnus Hagander
On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com wrote: Hi all, I got following stack:  fd7ffed14b70 strlen () + 40  fd7ffed71665 snprintf () + e5  fd7fff36d088 pg_GSS_startup () + 88  fd7fff36d43a pg_fe_sendauth () + 15a  fd7fff36e557 PQconnectPoll

Re: [HACKERS] psql with Function Type in \df

2010-02-25 Thread Bruce Momjian
Did we ever get tab completion support for these backslash commands? --- David Fetter wrote: On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote: David Fetter wrote: Is this any better? So what

Re: [HACKERS] psql 8.4 \c repeats version banner

2010-02-16 Thread Bruce Momjian
Applied. --- Bruce Momjian wrote: Peter Eisentraut wrote: In 8.3, running \c from a file prints something like You are now connected to database postgres. In 8.4 it prints psql (8.4.1) You are now

Re: [HACKERS] psql tab-completion for new syntax

2010-02-15 Thread Takahiro Itagaki
Here is a patch to support new syntax in psql tab completion and fix bugs to complete after an open parenthesis. Supported additonal syntax are: - ALTER TABLE/INDEX/TABLESPACE SET/RESET with options - ALTER TABLE ALTER COLUMN SET/RESET with options - ALTER TABLE ALTER COLUMN SET STORAGE -

Re: [HACKERS] psql tab completion for DO blocks

2010-02-14 Thread Takahiro Itagaki
David Fetter da...@fetter.org wrote: DO { [ LANGUAGE lang_name ] | code } ... Good catch :) The tab completion patch and documentation fix were committed. Thanks. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread David Fetter
On Wed, Feb 10, 2010 at 11:00:00AM +0900, Takahiro Itagaki wrote: Bruce Momjian br...@momjian.us wrote: Where are we on this patch? We should at least implement the completion for 'LANGUAGE' in 'DO', and use the existing pg_language query for completion. I am attaching a patch that does

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread Takahiro Itagaki
David Fetter da...@fetter.org wrote: Syntax of DO command is: DO code [ LANGUAGE lang_name ] That's not the only syntax. DO [LANGUAGE lang_name] code also works, e.g.: Hmmm, but we mention only above syntax in the documentation.

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread Euler Taveira de Oliveira
Takahiro Itagaki escreveu: Should we fix the documentation when we add the tab completion? Yes, it seems consistent with other commands having optional parameters in the middle of the command rather than at the end. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread David Fetter
On Fri, Feb 12, 2010 at 09:24:55AM +0900, Takahiro Itagaki wrote: David Fetter da...@fetter.org wrote: Syntax of DO command is: DO code [ LANGUAGE lang_name ] That's not the only syntax. DO [LANGUAGE lang_name] code also works, e.g.: Hmmm, but we mention only above

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread David Fetter
On Thu, Feb 11, 2010 at 11:26:10PM -0200, Euler Taveira de Oliveira wrote: Takahiro Itagaki escreveu: Should we fix the documentation when we add the tab completion? Yes, it seems consistent with other commands having optional parameters in the middle of the command rather than at the end.

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread Euler Taveira de Oliveira
David Fetter escreveu: It's consistent with how we do CREATE FUNCTION, where the order of parameters after RETURNS is arbitrary. If it is arbitrary the synopsis is wrong because it is imposing that code should be written after DO. It should be: DO { [ LANGUAGE lang_name ] | code } ... --

Re: [HACKERS] psql tab completion for DO blocks

2010-02-11 Thread David Fetter
On Fri, Feb 12, 2010 at 12:21:02AM -0200, Euler Taveira de Oliveira wrote: David Fetter escreveu: It's consistent with how we do CREATE FUNCTION, where the order of parameters after RETURNS is arbitrary. If it is arbitrary the synopsis is wrong because it is imposing that code should be

Re: [HACKERS] psql tab completion for DO blocks

2010-02-10 Thread Bruce Momjian
Takahiro Itagaki wrote: Bruce Momjian br...@momjian.us wrote: Where are we on this patch? We should at least implement the completion for 'LANGUAGE' in 'DO', and use the existing pg_language query for completion. I am attaching a patch that does exactly this. I don't think we need

Re: [HACKERS] psql tab completion for DO blocks

2010-02-09 Thread Takahiro Itagaki
Bruce Momjian br...@momjian.us wrote: Where are we on this patch? We should at least implement the completion for 'LANGUAGE' in 'DO', and use the existing pg_language query for completion. I am attaching a patch that does exactly this. I don't think we need the patch except adding DO to

Re: [HACKERS] psql 8.4 \c repeats version banner

2010-02-06 Thread Bruce Momjian
Peter Eisentraut wrote: In 8.3, running \c from a file prints something like You are now connected to database postgres. In 8.4 it prints psql (8.4.1) You are now connected to database postgres. Is it intentional/sensible to repeat the startup banner every time the connection

Re: [HACKERS] psql tab completion for DO blocks

2010-02-06 Thread Bruce Momjian
Robert Haas wrote: On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: On l?r, 2010-01-02 at 17:34 -0500, Tom Lane wrote: As for the overhead, these queries are not zero-maintenance. ?I still think that the usefulness of tab

Re: [HACKERS] psql tab completion recently broken?

2010-01-22 Thread Kevin Grittner
Kevin Grittner kevin.gritt...@wicourts.gov wrote: I just updated my source code and it no longer seems to work to type the following, and I'm pretty sure I was using it with a checkout from less than 24 hours ago: Never mind. My mistake. -Kevin -- Sent via pgsql-hackers mailing list

Re: [HACKERS] psql tab completion for DO blocks

2010-01-03 Thread Robert Haas
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote: As for the overhead, these queries are not zero-maintenance.  I still think that the usefulness of tab completion here is pretty darn

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread Tom Lane
David Fetter da...@fetter.org writes: Please find enclosed a patch which adds tab completion for DO blocks. Seems (a) rather pointless and (b) wrong in detail. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread David Fetter
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote: David Fetter da...@fetter.org writes: Please find enclosed a patch which adds tab completion for DO blocks. Seems (a) rather pointless and I don't find it so. (b) wrong in detail. How? That it can't look back past the code

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread Tom Lane
David Fetter da...@fetter.org writes: On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote: (b) wrong in detail. How? It doesn't actually work, because the query isn't paying attention to the current partial word. Try do language pltab, or just compare source to the original

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread David Fetter
On Sat, Jan 02, 2010 at 04:53:45PM -0500, Tom Lane wrote: David Fetter da...@fetter.org writes: On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote: (b) wrong in detail. How? It doesn't actually work, because the query isn't paying attention to the current partial word. Try do

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread Tom Lane
David Fetter da...@fetter.org writes: It doesn't actually work, because the query isn't paying attention to the current partial word. Try do language pltab, or just compare source to the original Query_for_list_of_languages. Thanks for the heads-up. New patch attached :) My inclination is

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread David Fetter
On Sat, Jan 02, 2010 at 05:10:08PM -0500, Tom Lane wrote: David Fetter da...@fetter.org writes: It doesn't actually work, because the query isn't paying attention to the current partial word. Try do language pltab, or just compare source to the original Query_for_list_of_languages.

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread Tom Lane
David Fetter da...@fetter.org writes: My inclination is to not have the separate query at all, I made one so people couldn't tab complete themselves an unpleasant surprise. The overhead doesn't seem huge. What unpleasant surprise is that going to be? They'll get an error message telling

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread Peter Eisentraut
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote: As for the overhead, these queries are not zero-maintenance. I still think that the usefulness of tab completion here is pretty darn minimal, since most people are more likely to rely on default_do_language; We really don't have any data on

Re: [HACKERS] psql tab completion for DO blocks

2010-01-02 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote: As for the overhead, these queries are not zero-maintenance. I still think that the usefulness of tab completion here is pretty darn minimal, since most people are more likely to rely on

Re: [HACKERS] psql 8.4 \c repeats version banner

2009-12-28 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: In 8.3, running \c from a file prints something like You are now connected to database postgres. In 8.4 it prints psql (8.4.1) You are now connected to database postgres. Is it intentional/sensible to repeat the startup banner every time the

Re: [HACKERS] psql password passing problem

2009-08-14 Thread Serge Fonville
Hi, I'd like to inform you about the issue of using psql in a dos batch file on windows vista. On linux all is very simple, you can easily write in your script psql -d mydb -U myuser -f myqry.sql passw.txt On windows however, psql does not seem to work like this, nor does type

Re: [HACKERS] psql - small fix in \du

2009-07-24 Thread Peter Eisentraut
On Thursday 23 July 2009 13:29:51 Andreas Wenk wrote: attached you can find an updated patch. The changes are: - change \du and \dg to \du+ and \dg+ in the docu - change the same in psql/help.c - change the translation files in psql/po Fixed, thanks. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] psql - small fix in \du

2009-07-23 Thread Andreas Wenk
Tom Lane schrieb: Andreas Wenk a.w...@netzmeister-st-pauli.de writes: I am not sure when the function shobj_description(oid, name) is giving a result. That retrieves the comment for the object (the role, in this case). regards, tom lane attached you can find an

Re: [HACKERS] psql - small fix in \du

2009-07-22 Thread Andreas Wenk
ANdreas Wenk schrieb: Hi, attached you can find a very small patch for the help in psql (\?). It's possible to use \du also as \du+ . The [+] was missing in help. I was asking about this at the general list and Peter E. was asking me to provide a patch. I sent the patch there but realized

Re: [HACKERS] psql - small fix in \du

2009-07-22 Thread Tom Lane
Andreas Wenk a.w...@netzmeister-st-pauli.de writes: I am not sure when the function shobj_description(oid, name) is giving a result. That retrieves the comment for the object (the role, in this case). regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] psql - small fix in \du

2009-07-22 Thread Andreas Wenk
Tom Lane wrote: Andreas Wenk a.w...@netzmeister-st-pauli.de writes: I am not sure when the function shobj_description(oid, name) is giving a result. That retrieves the comment for the object (the role, in this case). regards, tom lane Tom, thank you. I will provide

Re: [HACKERS] psql \du and \dg is the same - pg 8.4

2009-07-21 Thread Tom Lane
ANdreas Wenk a.w...@netzmeister-st-pauli.de writes: actually I discovered that using \du and \dg in psql is providing the same result: Yup. The psql documentation says as much. I am wondering why there is \dg at all. Users and groups used to be distinct kinds of objects. They aren't

Re: [HACKERS] psql \du and \dg is the same - pg 8.4

2009-07-21 Thread Andreas Wenk
Tom Lane wrote: ANdreas Wenk a.w...@netzmeister-st-pauli.de writes: actually I discovered that using \du and \dg in psql is providing the same result: Yup. The psql documentation says as much. ok - got it ;-) Should have read the psql docu ... I am wondering why there is \dg at all.

Re: [HACKERS] psql is broken in 8.4

2009-05-23 Thread Zdenek Kotala
Heikki Linnakangas píše v čt 21. 05. 2009 v 16:53 +0300: Zdenek Kotala wrote: Another problem is with resultset. When I run for example following command I got this output: postgres=# select oid from pg_am; oid -- 403 405 783 2742  That's odd. Work for

Re: [HACKERS] psql is broken in 8.4

2009-05-21 Thread Heikki Linnakangas
Zdenek Kotala wrote: last version of psql is broken: psql (8.4beta1, server 8.3.7) WARNING: psql version 8.4, server version 8.3. Some psql features might not work. Type help for help. postgres=# \d test ERROR: syntax error at or near , LINE 1: ...index, relhasrules, reltriggers 0,

Re: [HACKERS] psql is broken in 8.4

2009-05-21 Thread Zdenek Kotala
Heikki Linnakangas píše v čt 21. 05. 2009 v 16:53 +0300: Zdenek Kotala wrote: last version of psql is broken: psql (8.4beta1, server 8.3.7) WARNING: psql version 8.4, server version 8.3. Some psql features might not work. Type help for help. postgres=# \d test ERROR:

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread Alvaro Herrera
David Fetter wrote: On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote: It also seems like we're missing tab completion support for this. Oops. Working on that now. Any luck with this? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread David Fetter
On Mon, Apr 27, 2009 at 10:39:33AM -0400, Alvaro Herrera wrote: David Fetter wrote: On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote: It also seems like we're missing tab completion support for this. Oops. Working on that now. Any luck with this? I have a handle on

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread Tom Lane
David Fetter da...@fetter.org writes: I have a handle on the problem, which is that the tab completion code assumes, wrongly, that it only needs to deal with fixed strings. It's actually been false for some time in the \div case, for example. The S option has shattered the fixed-string

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread David Fetter
On Mon, Apr 27, 2009 at 01:11:44PM -0400, Tom Lane wrote: David Fetter da...@fetter.org writes: I have a handle on the problem, which is that the tab completion code assumes, wrongly, that it only needs to deal with fixed strings. It's actually been false for some time in the \div case,

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread Alvaro Herrera
David Fetter wrote: On Mon, Apr 27, 2009 at 01:11:44PM -0400, Tom Lane wrote: It seems like rather a large change to be making in beta. Can you make a small patch that fixes the immediate problem, and leave the refactoring for 8.5? The hack I've come up with short of the refactor is to

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread David Fetter
On Mon, Apr 27, 2009 at 01:31:11PM -0400, Alvaro Herrera wrote: David Fetter wrote: On Mon, Apr 27, 2009 at 01:11:44PM -0400, Tom Lane wrote: It seems like rather a large change to be making in beta. Can you make a small patch that fixes the immediate problem, and leave the

Re: [HACKERS] psql with Function Type in \df

2009-04-27 Thread Alvaro Herrera
David Fetter wrote: On Mon, Apr 27, 2009 at 01:31:11PM -0400, Alvaro Herrera wrote: Tab completion has never been perfect. I don't think beta is the best time to be improving it so much. I think a small patch that just adds \dfa, \dfw and appropriate pattern completions (i.e. it lists

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread Bruce Momjian
to...@tuxteam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 21, 2009 at 01:26:33PM -0400, Bruce Momjian wrote: [...] I merged the entries into one line: \df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions I didn't feel I had room

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread tomas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 22, 2009 at 08:32:20AM -0400, Bruce Momjian wrote: [...] True, but the problem is that the brackets don't correspond [...] Yes, right. Still, square brackets seem (to me) to provide some visual cue. But I admit that this is already

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread Bruce Momjian
to...@tuxteam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 22, 2009 at 08:32:20AM -0400, Bruce Momjian wrote: [...] True, but the problem is that the brackets don't correspond [...] Yes, right. Still, square brackets seem (to me) to provide some visual cue.

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: If I can get someone else to say they prefer brackets over parentheses in \? I will make the change. Right now we have: \df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions With brackets it would be: \df[antwS+] [PATTERN]

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread Alvaro Herrera
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: If I can get someone else to say they prefer brackets over parentheses in \? I will make the change. Right now we have: \df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions With brackets it would be:

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Still, my original proposal was \df[antw][S+]. The extra brackets are obviously redundant, but if we're about providing cues, this is a good cue IMO. It allows the [S+] to match the other lines. I'm for that too. Bruce was complaining that

Re: [HACKERS] psql with Function Type in \df

2009-04-22 Thread Bruce Momjian
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Still, my original proposal was \df[antw][S+]. The extra brackets are obviously redundant, but if we're about providing cues, this is a good cue IMO. It allows the [S+] to match the other lines. I'm for that too. Bruce

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Bruce Momjian
David Fetter wrote: On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote: David Fetter wrote: I think it's good to have them translatable. As for using aggregate instead of agg I don't think it's that great an idea. If you need to notify translators that agg

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Kevin Grittner
Bruce Momjian br...@momjian.us wrote: \df[S+] [PATTERN] list functions \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions Shouldn't that second line have some curly braces? Like maybe: \df{antw}[S+] [PATTERN] list only agg/normal/trigger/window functions

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Alvaro Herrera
Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: \df[S+] [PATTERN] list functions \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions Shouldn't that second line have some curly braces? Like maybe: \df{antw}[S+] [PATTERN] list only

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Joshua D. Drake
On Tue, 2009-04-21 at 12:19 -0400, Alvaro Herrera wrote: I suggested this to Bruce over IM: \df[antw][S+] list [only agg/normal/trigger/window] functions (one line only, removing the second redundant line). This seems clea[nr]er to me. Bruce says it would confuse users. But really,

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Bruce Momjian
Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: \df[S+] [PATTERN] list functions \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions Shouldn't that second line have some curly braces? Like maybe: \df{antw}[S+] [PATTERN] list only

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Kevin Grittner
Alvaro Herrera alvhe...@commandprompt.com wrote: \df[antw][S+] list [only agg/normal/trigger/window] functions (one line only, removing the second redundant line). This seems clea[nr]er to me. Bruce says it would confuse users. That's clear to me, anyway (if you include PATTERN).

Re: [HACKERS] psql with Function Type in \df

2009-04-21 Thread Kevin Grittner
Bruce Momjian br...@momjian.us wrote: The problem is I don't see curly braces used anywhere in \? I see it in 8.3: : \d{t|i|s|v|S} [PATTERN] (add + for more detail) :list tables/indexes/sequences/views/system tables and: : \pset NAME [VALUE] :set table

<    5   6   7   8   9   10   11   12   13   14   >