Robert Haas robertmh...@gmail.com writes:
On the other hand, I am also not entirely sure such a change in
terminology would be a net improvement in clarity, even though it does
seem better in some cases. For example, the CREATE TABLE command does
not create a viewed table; nor is there any
On tor, 2011-08-04 at 14:59 -0400, Robert Haas wrote:
Well, the facts are: According to the SQL standard, table
includes
views and foreign tables. According to scientific-ish database
literature, a table is a relation and vice versa.
So what are you supposed to call it if you mean,
On Fri, Aug 12, 2011 at 4:11 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-08-04 at 14:59 -0400, Robert Haas wrote:
Well, the facts are: According to the SQL standard, table
includes
views and foreign tables. According to scientific-ish database
literature, a table is a
2011/8/9 Shigeru Hanada shigeru.han...@gmail.com:
I'm the author of that patch, sorry for confusion. May I explain the
background of implementing those command? :)
Basically, during implementing foreign table support, I tried to follow
the existing design.
I found two backslash command
On Mon, Aug 8, 2011 at 6:01 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Mon, Aug 8, 2011 at 4:34 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I've now committed most of this, with some additions to the
documentation. Remaining bits attached.
Looks good, thanks.
And now I've
2011/8/9 Shigeru Hanada shigeru.han...@gmail.com:
postgres=# \d pgbench_accounts
Foreign table public.pgbench_accounts
Column | Type | Modifiers | Options
--+---+---+---
aid | integer | not null | {colname=aid}
bid
(2011/08/12 0:48), Robert Haas wrote:
2011/8/9 Shigeru Hanadashigeru.han...@gmail.com:
postgres=# \d pgbench_accounts
Foreign table public.pgbench_accounts
Column | Type | Modifiers |Options
--+---+---+---
aid | integer
2011/8/11 Shigeru Hanada shigeru.han...@gmail.com:
Yeah, I have (hopefully) working FDW for PostgreSQL which is based on
the one which has been proposed for 9.1, and updates done by Heikki.
I've implemented:
* SELECT clause omitting
* WHERE clause pushdown (assuming remote has same
(2011/08/09 7:01), Josh Kupershmidt wrote:
I am a bit confused as to why we have both \det and \dE. They seem
redundant. Shouldn't we rip one of those out? IMHO, \det should be
the one to go, as it could be useful to do, e.g. \dtvE, which isn't
going to work with the \det syntax.
Yeah, I
2011/8/8 Shigeru Hanada shigeru.han...@gmail.com:
I noticed that psql document wrongly says that \d+ command shows
per-table FDW options of a foreign table, but in fact, per-table FDW
options are shown only in the result of \det+ command. Attached patch
removes this wrong description.
This
On Fri, Aug 5, 2011 at 7:25 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Fri, Aug 5, 2011 at 8:32 AM, Robert Haas robertmh...@gmail.com wrote:
I guess my vote is to make the SQL/MED stuff show the description only
in verbose mode, and always at the end; and revise what we did with
\dL to
On Mon, Aug 8, 2011 at 4:34 PM, Robert Haas robertmh...@gmail.com wrote:
OK, I've now committed most of this, with some additions to the
documentation. Remaining bits attached.
Looks good, thanks.
I am a bit confused as to why we have both \det and \dE. They seem
redundant. Shouldn't we
On Mon, Aug 8, 2011 at 6:01 PM, Josh Kupershmidt schmi...@gmail.com wrote:
(i.e. add Options column to \dE+ if we keep that one).
Oh nevermind, Options is displayed by \d+ foreign_table_name.
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, Aug 4, 2011 at 10:24 PM, Josh Kupershmidt schmi...@gmail.com wrote:
A few existing backslash commands, such as \dn and maybe \db, don't
exactly follow this precedent. Not sure if we want to bother adjusting
the existing commands to be consistent in this regard. Defining
typical usage
On ons, 2011-07-27 at 17:57 -0400, Josh Kupershmidt wrote:
I think table_name is fine, and if you are very worried, add below
that
a table_name also includes views (or whatever).
It includes tables, views, composite types, and foreign tables. Is
table really an appropriate description for
On ons, 2011-07-27 at 18:08 -0400, Robert Haas wrote:
Also, while it may be true that we haven't used the term specifically
in SQL sypnoses, it's been extensively used in other parts of the
documentation, in the names of system functions such as
pg_relation_size(),
Well, that thing is just
On Thu, Aug 4, 2011 at 2:30 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-07-27 at 18:08 -0400, Robert Haas wrote:
Also, while it may be true that we haven't used the term specifically
in SQL sypnoses, it's been extensively used in other parts of the
documentation, in the names of
On Thu, Aug 4, 2011 at 2:26 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-07-27 at 17:57 -0400, Josh Kupershmidt wrote:
I think table_name is fine, and if you are very worried, add below
that
a table_name also includes views (or whatever).
It includes tables, views, composite
Peter Eisentraut pete...@gmx.net wrote:
According to scientific-ish database literature, a table is a
relation and vice versa.
I've generally understood the terms more like what is described near
the top of this page:
http://en.wikipedia.org/wiki/Relation_%28database%29
In SQL, [...] a
On Thu, 2011-08-04 at 14:20 -0500, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
According to scientific-ish database literature, a table is a
relation and vice versa.
I've generally understood the terms more like what is described near
the top of this page:
On Thu, Aug 4, 2011 at 12:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 26, 2011 at 8:38 PM, Josh Kupershmidt schmi...@gmail.com wrote:
[new patch]
I've committed the portion of this that displays comments on languages
and casts.
Thanks!
For domains and conversions, I am
Robert Haas robertmh...@gmail.com wrote:
Peter Eisentraut pete...@gmx.net wrote:
I would like to argue for reverting this. If you want to
word-smith details like this, relation doesn't carry any
additional meaning. PG hackers know that internally, a
relation is a table, view, index,
On Tue, Jul 26, 2011 at 9:21 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Tue, Jul 26, 2011 at 9:53 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt schmi...@gmail.com
wrote:
I think this is basically the right approach but I found what you
On tis, 2011-07-26 at 09:53 -0400, Robert Haas wrote:
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt
schmi...@gmail.com wrote:
That seems like a good way to document this; patch for master
updated.
I avoided mucking with the documentation for COMMENT ON RULE and
COMMENT ON TRIGGER
On Wed, Jul 27, 2011 at 5:19 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-07-26 at 09:53 -0400, Robert Haas wrote:
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt
schmi...@gmail.com wrote:
That seems like a good way to document this; patch for master
updated.
I avoided
On Wed, Jul 27, 2011 at 5:19 PM, Peter Eisentraut pete...@gmx.net wrote:
I would like to argue for reverting this. If you want to word-smith
details like this, relation doesn't carry any additional meaning. PG
hackers know that internally, a relation is a table, view, index,
sequence, etc.,
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt schmi...@gmail.com wrote:
That seems like a good way to document this; patch for master updated.
I avoided mucking with the documentation for COMMENT ON RULE and
COMMENT ON TRIGGER this time; they both say table when they really
mean table or
On Tue, Jul 26, 2011 at 9:53 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I think this is basically the right approach but I found what you did
here a bit wordy, so I simplified it, committed it, and back-patched
to
On Fri, Jul 22, 2011 at 10:44 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sat, Jul 9, 2011 at 1:16 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Attached is an updated version of this patch, lifted out of the recent
pg_comments patch. With this v2 patch, \dd should properly show just
On Fri, Jul 22, 2011 at 12:44 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 21, 2011 at 9:17 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Here's a small patch against branch 8.4 to mention support for COMMENT
ON index_name.column_name.
I am not in favor of this - because we'd
On Thu, Jul 21, 2011 at 9:17 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Here's a small patch against branch 8.4 to mention support for COMMENT
ON index_name.column_name.
I am not in favor of this - because we'd also need to mention every
other relkind that can support comments. I think if
On Sun, Jul 17, 2011 at 10:54 AM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sat, Jul 16, 2011 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
After a bit of review of the archives, the somebody was me:
On Sat, Jul 16, 2011 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
After a bit of review of the archives, the somebody was me:
http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=b7d67954456f15762c04e5269b64adc88dcd0860
and this thread was the discussion about it:
Josh Kupershmidt schmi...@gmail.com writes:
So, if you look at \d+ newtbl, the right-most column named Description
should display any comments attached to newtbl's columns. You should
see bcol column comment as the Description for column bcol. That
works OK.
Right.
Now, try this:
test=#
I wrote:
Josh Kupershmidt schmi...@gmail.com writes:
What's the Description displayed in that table?
What it ought to be is the comment (if any) attached to the index's
column. Up through 8.4 this worked as expected, but in 9.0 and up
somebody seems to have disallowed comments on index
On Sat, Jul 16, 2011 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Josh Kupershmidt schmi...@gmail.com writes:
What's the Description displayed in that table?
What it ought to be is the comment (if any) attached to the index's
column. Up through 8.4 this worked as expected, but
On Thu, Jun 16, 2011 at 10:05 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Jun 15, 2011 at 9:01 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jun 14, 2011 at 9:08 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure mmonc...@gmail.com
On Wed, Jun 15, 2011 at 9:01 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jun 14, 2011 at 9:08 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure mmonc...@gmail.com wrote:
What I do wonder though is if the ; appending should really be
On Tue, Jun 14, 2011 at 9:08 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure mmonc...@gmail.com wrote:
What I do wonder though is if the ; appending should really be
happening in printQuery() instead of in each query -- the idea being
that
On Sat, May 7, 2011 at 2:40 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Hi all,
I use psql's -E mode every now and then, copy-and-pasting and further
tweaking the SQL displayed. Most queries are displayed terminated by a
semicolon, but quite a few aren't, making copy-and-paste just a bit
Excerpts from Josh Kupershmidt's message of sáb may 07 16:40:35 -0300 2011:
And while I'm griping about describe.c, is it just me or is the source
code indentation in that file totally screwy? I'm using emacs and I've
loaded the snippet for pgsql-c-mode from
./src/tools/editors/emacs.samples
On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure mmonc...@gmail.com wrote:
I did a quick review and test of your patch. It didn't quite apply
cleanly due to recent non-related describe.c changes -- updated patch
attached.
Thanks for looking at this. Your updated patch looks good to me.
On Tue, Jun 14, 2011 at 3:25 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
pgindent moves strings back to the left when it thinks they fit within
80 columns. Yes, that seems pretty screwy.
I am losing track of the ways in which pgindent has managed to mangle
our source code :-/
Josh
On Sat, May 28, 2011 at 10:38 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Hi all,
psql's auto-complete support for COMMENT ON was missing support for a
few object types:
1.) EXTENSION and PROCEDURAL LANGUAGE are now auto-complete candidates
for COMMENT ON [TAB]. Lists of extensions and
On lör, 2011-05-07 at 15:40 -0400, Josh Kupershmidt wrote:
And while I'm griping about describe.c, is it just me or is the source
code indentation in that file totally screwy? I'm using emacs and I've
loaded the snippet for pgsql-c-mode from
./src/tools/editors/emacs.samples into my ~/.emacs,
Re: Tom Lane 2011-04-03 1397.1301782...@sss.pgh.pa.us
Yeah, that's clearly a bug --- fix committed, thanks for the patch!
It could explain Devrim's report if the parameters passed by psql had
some problem that was detectable by conninfo_array_parse(). That seems
a bit unlikely, but I did
Christoph Berg c...@df7cb.de writes:
I'm still seeing that problem: 9.1 HEAD compiled in my $HOME, with
Debian's 9.0.1-2 libpq5 in /usr/lib:
$ LC_ALL=C bin/psql
psql: connection pointer is NULL
Upgrading to libpq5 9.0.4-1 makes things a bit better:
$ LC_ALL=C bin/psql
psql: invalid
On Thu, Apr 7, 2011 at 3:03 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 28. März 2011 13:38:23 +0100 Bernd Helmle maili...@oopsware.de wrote:
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables.
--On 28. März 2011 13:38:23 +0100 Bernd Helmle maili...@oopsware.de wrote:
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables. Anyone see a problem with that?
Hmm yeah, seems i was thinking too
Peter Eisentraut pete...@gmx.net wrote:
Wouldn't it be better if there were a setting in psql that set the
linestyle to unicode only if the client encoding was actually
UTF8?
Is UTF8 the only client encoding in which we currently support the
Unicode character set?
-Kevin
--
Sent via
On Thu, Apr 07, 2011 at 02:49:29PM -0500, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
Wouldn't it be better if there were a setting in psql that set the
linestyle to unicode only if the client encoding was actually
UTF8?
Is UTF8 the only client encoding in which we
On Sat, 2011-04-02 at 18:10 -0400, Tom Lane wrote:
It could explain Devrim's report if the parameters passed by psql had
some problem that was detectable by conninfo_array_parse(). That
seems a bit unlikely, but I did think of one possibility: if Devrim
was
testing 9.1 psql with a 9.0
2011/4/2 Devrim GÜNDÜZ dev...@gunduz.org:
I'm getting the following message after upgrading to Alpha5 on my Fedora
14 box:
$ psql -p 5433
psql: connection pointer is NULL
which comes from libpq. Server is running, and I can connect it to via
9.0's psql.
This is a regular RPM build. Am I
Joseph Adams joeyadams3.14...@gmail.com writes:
I couldn't reproduce this (using upstream source on Ubuntu). However,
I did find a little bug in libpq causing the connection handle to
become NULL in the event of an option parsing error. This bug has
been around since release 9.0.0, and may
--On 26. März 2011 21:59:18 -0400 Robert Haas robertmh...@gmail.com
wrote:
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables. Anyone see a problem with that?
Hmm yeah, seems i was thinking too
On Wed, Mar 23, 2011 at 4:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote:
It stroke me today again, that \dt+ isn't displaying the acurate
On Sat, Mar 26, 2011 at 9:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 23, 2011 at 4:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de
Excerpts from Pavel Stehule's message of vie mar 25 02:48:49 -0300 2011:
2011/3/24 Robert Haas robertmh...@gmail.com:
On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
can we enhance a detail for table and show more accurate numbers?
table size: xxx
toast
2011/3/25 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Pavel Stehule's message of vie mar 25 02:48:49 -0300 2011:
2011/3/24 Robert Haas robertmh...@gmail.com:
On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
can we enhance a detail for table and
On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2011/3/23 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote:
It stroke me
2011/3/24 Robert Haas robertmh...@gmail.com:
On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2011/3/23 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle
Hello Bernd,
On 21.03.2011 18:44, Bernd Helmle wrote:
Attached minor patch extends \dt to use pg_table_size() starting with
PostgreSQL 9.0, not sure if we backport such changes though. It would
be interesting for 9.1, however.
As I already told you:
I tested and it worked.
The code looks
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote:
It stroke me today again, that \dt+ isn't displaying the acurate table size
for tables, since it uses pg_relation_size() till now. With having
pg_table_size() since PostgreSQL 9.0 available, i believe it would be more
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote:
It stroke me today again, that \dt+ isn't displaying the acurate table size
for tables, since it uses pg_relation_size() till now. With having
2011/3/23 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote:
It stroke me today again, that \dt+ isn't displaying the acurate table size
for tables, since
2011/3/22 David Fetter da...@fetter.org:
+1 for fixing this behavior in 9.1. -1 for changing in 9.0, as the
change in behavior mid-release will cause more confusion than the
incomplete accounting does.
Idem.
Cheers,
David.
On Mon, Mar 21, 2011 at 06:44:51PM +0100, Bernd Helmle wrote:
+1 for fixing this behavior in 9.1. -1 for changing in 9.0, as the
change in behavior mid-release will cause more confusion than the
incomplete accounting does.
Cheers,
David.
On Mon, Mar 21, 2011 at 06:44:51PM +0100, Bernd Helmle wrote:
It stroke me today again, that \dt+ isn't displaying the
I have added a link to this on the TODO list:
Add auto expanded mode that outputs in expanded format if wrapped
mode can't wrap the output to the screen width
* Re: psql wrapped format default for backslash-d commands
*
On Sun, Feb 27, 2011 at 01:21, Josh Kupershmidt schmi...@gmail.com wrote:
Hi all,
I noticed an off by one error in psql's verbose-mode display for \dg
and \du. In verbose mode, \dg and \du will not display the
Replication attribute:
test=# \dg rep
List of roles
Role name |
On Sun, Feb 13, 2011 at 7:52 AM, Peter Eisentraut pete...@gmx.net wrote:
psql -l doesn't process psqlrc. Historically, this was probably not
useful, hence no one cared. But with the linestyle option it's useful.
So I propose the attached tweak.
As a violent hater of the new linestyle, +1
On Thu, Feb 10, 2011 at 8:13 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Thu, Feb 10, 2011 at 19:37, Christoph Berg c...@df7cb.de wrote:
Currently, tab-completing :variable names in psql does not work at the
beginning of the line. Fix this by moving the code block before the
On Thu, Feb 10, 2011 at 19:37, Christoph Berg c...@df7cb.de wrote:
Currently, tab-completing :variable names in psql does not work at the
beginning of the line. Fix this by moving the code block before the
empty buffer case.
Seems reasonable to me.
--
Itagaki Takahiro
--
Sent via
On Tue, 2011-01-18 at 19:34 -0500, Josh Kupershmidt wrote:
Got that now too. I lost my ~/.emacs file recently, which is mostly
why I'm making whitespace mistakes. Rebuilding slowly though;
(setq-default show-trailing-whitespace t) is what I needed.
Aha, I see.
I left the Call Handler and
On Wed, Jan 19, 2011 at 5:47 PM, Andreas Karlsson andr...@proxel.se wrote:
The patch looks alright now so I will mark it as ready for committer
now.
This patch doesn't seem terribly consistent to me - we show the name
of the call handler and the name of the validator, but for the inline
handler
On Wed, Jan 19, 2011 at 9:09 PM, Robert Haas robertmh...@gmail.com wrote:
This patch doesn't seem terribly consistent to me - we show the name
of the call handler and the name of the validator, but for the inline
handler we just indicate whether there is one or not. That seems like
something
On Wed, Jan 19, 2011 at 11:19 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Wed, Jan 19, 2011 at 9:09 PM, Robert Haas robertmh...@gmail.com wrote:
This patch doesn't seem terribly consistent to me - we show the name
of the call handler and the name of the validator, but for the inline
Hi Josh,
Nope, I do not have any better ideas than DO Blocks?.
Everything looks good with the exception one bug now.
\dL foo
* QUERY **
SELECT l.lanname AS Name,
pg_catalog.pg_get_userbyid(l.lanowner) as Owner,
l.lanpltrusted AS Trusted
FROM pg_catalog.pg_language
On Tue, Jan 18, 2011 at 1:35 PM, Andreas Karlsson andr...@proxel.se wrote:
Hi Josh,
Nope, I do not have any better ideas than DO Blocks?.
Everything looks good with the exception one bug now.
\dL foo
* QUERY **
SELECT l.lanname AS Name,
On mån, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote:
which, as Magnus points out, includes non-procedural languages (SQL).
I think that list languages could be confusing to newcomers -- the
very people who might be reading through the help output of psql for
the first time -- who
On Mon, Jan 17, 2011 at 02:48:43PM +0200, Peter Eisentraut wrote:
On mån, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote:
which, as Magnus points out, includes non-procedural languages
(SQL).
I think that list languages could be confusing to newcomers
-- the very people who might
Peter Eisentraut wrote:
On m?n, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote:
which, as Magnus points out, includes non-procedural languages (SQL).
I think that list languages could be confusing to newcomers -- the
very people who might be reading through the help output of psql
On Mon, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote:
Yeah. Procedural langauges may strictly be wrong, but people aren't
likely to misunderstand it.
That was idea when suggesting we call it procedural languages. It is
short and I do not think it can be misunderstood.
Regards,
Andreas
On Sun, 2011-01-16 at 22:32 -0500, Josh Kupershmidt wrote:
On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson andr...@proxel.se wrote:
Should we include a column in \dL+ for the laninline function (DO
blocks)?
Hrm, I guess that could be useful for the verbose output at least.
Magnus
Hi all,
I've updated the patch to address the following points:
* help string now says list procedural languages (no parentheses now)
* the language name column is now titled Name
* added another column in verbose mode for 9.0+ showing whether DO
blocks are possible with the language. I named
On Sun, Jan 16, 2011 at 02:26, Andreas Karlsson andr...@proxel.se wrote:
Hi Josh,
Contents and Purpose
This patch adds the \dL command in psql to list the procedual languages.
snip
Some things I noticed when using it though.
I do not like the use of parentheses in
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net wrote:
I do not like the use of parentheses in the usage description list
(procedural) languages. Why not have it simply as list procedural
languages?
Because it lists non-procedural langauges as well? (I didn't check it,
On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson andr...@proxel.se wrote:
Hi Josh,
Here is my review of this patch for the commitfest.
Review of https://commitfest.postgresql.org/action/patch_view?id=439
Thanks a lot for the review!
Contents and Purpose
This patch
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net wrote:
I do not like the use of parentheses in the usage description list
(procedural) languages. Why not have it simply as list procedural
languages?
On Sun, Jan 16, 2011 at 10:40 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net wrote:
I do not like the use of parentheses in the usage description list
On Mon, Jan 17, 2011 at 05:22, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 10:40 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net
Hi Josh,
Here is my review of this patch for the commitfest.
Review of https://commitfest.postgresql.org/action/patch_view?id=439
Contents and Purpose
This patch adds the \dL command in psql to list the procedual languages.
To me this seems like a useful addition to the
2011/1/13 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
I found a crash case (assertion failure) when runing psql -f
utf8_encoded_script.sql against client_encoding = shift_jis in
postgresql.conf. Though encoding mismatch is obviously user's fault, a
crash doesn't
Hitoshi Harada umi.tan...@gmail.com writes:
I found a crash case (assertion failure) when runing psql -f
utf8_encoded_script.sql against client_encoding = shift_jis in
postgresql.conf. Though encoding mismatch is obviously user's fault, a
crash doesn't explain anything to him.
I'm not too
Peter Eisentraut wrote:
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
Attached is a crude demo patch. Enable with \pset expanded auto.
It is a TODO:
Add
pete...@gmx.net (Peter Eisentraut) writes:
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
I haven't tested the patch, but that *does* sound generally useful.
It's no fun trying to
On Sat, Dec 18, 2010 at 07:12, Peter Eisentraut pete...@gmx.net wrote:
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
+1
Attached is a crude demo patch. Enable with \pset
On Sun, Nov 21, 2010 at 8:18 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I'd like to revive Fernando Ike's patch implementing the \dL command
for psql to list available languages, last version here:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php
Please add this patch to
On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas robertmh...@gmail.com wrote:
Please add this patch to the currently open CommitFest:
Added to 2011-01.
https://commitfest.postgresql.org/action/commitfest_view/open
And please also help with review of patches from the current CommitFest:
On Sun, Nov 21, 2010 at 9:44 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas robertmh...@gmail.com wrote:
Please add this patch to the currently open CommitFest:
Added to 2011-01.
https://commitfest.postgresql.org/action/commitfest_view/open
And
On ons, 2010-10-20 at 22:56 -0400, Josh Kupershmidt 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 and \du are the
801 - 900 of 1586 matches
Mail list logo
