On Mon, Apr 23, 2012 at 12:30 PM, Noah Misch n...@leadboat.com wrote:
Looks like the logic in printQuery() needs further treatment.
Do you want to propose a patch, or are you hoping someone else is
going to address this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Wed, Apr 25, 2012 at 04:57:36PM -0400, Robert Haas wrote:
On Mon, Apr 23, 2012 at 12:30 PM, Noah Misch n...@leadboat.com wrote:
Looks like the logic in printQuery() needs further treatment.
Do you want to propose a patch, or are you hoping someone else is
going to address this?
I
On tis, 2012-04-10 at 17:48 -0700, Josh Kupershmidt wrote:
Hmm, but now you've set it up so that you can complete ALTER ROLE
foo
WITH WITH. Were you aware of that?
D'oh, I overlooked that. Attached is v2: the diff is a tad lengthier
now, but that should fix it.
Committed.
--
Sent via
On tis, 2012-04-03 at 22:34 -0700, Josh Kupershmidt wrote:
I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
try to tab-complete commands like:
ALTER ROLE jsmith WITH [TAB]
COPY tbl FROM 'filename' WITH [TAB]
you'll get 'RECURSIVE' unhelpfully filled in. I think
On Tue, Apr 10, 2012 at 10:38 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2012-04-03 at 22:34 -0700, Josh Kupershmidt wrote:
I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
try to tab-complete commands like:
ALTER ROLE jsmith WITH [TAB]
COPY tbl FROM
Excerpts from Noah Misch's message of jue mar 08 12:11:37 -0300 2012:
On Wed, Mar 07, 2012 at 04:57:12PM -0500, Robert Haas wrote:
As a side note, the documentation for PQexec() is misleading about
what will happen if COPY is present in a multi-command string. It
says: Note however
On Wed, Mar 07, 2012 at 04:57:12PM -0500, Robert Haas wrote:
On Sat, Feb 25, 2012 at 12:57 AM, Noah Misch n...@leadboat.com wrote:
Thanks. ?While testing a crashing function, I noticed that my above patch
added some noise to psql output when the server crashes:
[local] test=# select
On Sat, Feb 25, 2012 at 12:57 AM, Noah Misch n...@leadboat.com wrote:
Thanks. While testing a crashing function, I noticed that my above patch
added some noise to psql output when the server crashes:
[local] test=# select crashme();
The connection to the server was lost. Attempting reset:
Excerpts from Noah Misch's message of sáb ene 14 12:20:18 -0300 2012:
Occasionally, I have a SQL file destined for psql's \i command whose name
contains a space. Less often, I'll have a .csv destined for \copy with the
same problem. psql's filename completion does not handle these well. It
On Fri, Feb 24, 2012 at 9:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, what I should have asked is are you running Lion?.
Because with libedit on Lion, tab completion is 100% broken, as per
http://archives.postgresql.org/pgsql-hackers/2011-07/msg01642.php
This is just the latest
On Thu, Feb 23, 2012 at 4:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Here's a reliable reproduction on my OS X laptop.
OS X? Are you using GNU readline, or Apple's libedit?
I reproduced it with both, but if that news is surprising to you, I
can certainly re-test.
--
Peter van Hardenberg
San
Peter van Hardenberg p...@pvh.ca writes:
On Thu, Feb 23, 2012 at 4:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Here's a reliable reproduction on my OS X laptop.
OS X? Are you using GNU readline, or Apple's libedit?
I reproduced it with both, but if that news is surprising to you, I
can
On Wed, Jan 25, 2012 at 06:25:46PM -0300, Alvaro Herrera wrote:
Excerpts from Noah Misch's message of s??b ene 14 12:40:02 -0300 2012:
It has bothered me that psql's \copy ignores the ON_ERROR_ROLLBACK setting.
Only SendQuery() takes note of ON_ERROR_ROLLBACK, and \copy, like all
backslash
Peter van Hardenberg p...@pvh.ca writes:
While testing Noah's filename quoting patch on my local development
machine, I noticed some strange behaviour around tab completion with
\i; it doesn't appear to be present in 9.1, but it is present on 9.2
HEAD and appears to be present with and without
On tor, 2012-02-09 at 23:02 +0100, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
Make tab-completion complete also function names – like: SELECT
pg_gettabtab to see all functions that start with pg_get.
Make tab-completion work for columns in SELECT. I know that when
On fre, 2012-02-10 at 01:24 -0500, Tom Lane wrote:
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a function name? I would
think it would be a column name (from who-knows-what table) much more
often.
That's what the patch
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word
2012/2/10 Robert Haas robertmh...@gmail.com:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus.
On 10/02/12 08:50, Robert Haas wrote:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus. What
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a function name?
It isn't necessarily, but it might be. It'd
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not against tab-completing functions, if people think that's
useful. I am against tab-completing them in 1% of use-cases, which is
what this patch accomplishes. The fact that
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not against tab-completing functions, if people think that's
useful. I am against tab-completing them in 1%
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you want a patch with low standards, what about tab-completing
function names anywhere that we do not see context suggesting something
else?
I think that without a bit more
On Fri, Feb 10, 2012 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you want a patch with low standards, what about tab-completing
function names anywhere that we do not see
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Haas wrote:
One thing that's been bugging me for a while is that the tab
completion code all works by looking backward up to n words. What we
really want to know is what kind of statement we're in and where we
are in it. Absent
Peter Eisentraut pete...@gmx.net writes:
Make tab-completion complete also function names – like: SELECT
pg_gettabtab to see all functions that start with pg_get.
Make tab-completion work for columns in SELECT. I know that when writing
SELECT clause, psql doesn’t know which table it will deal
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a function name? I would
think it would be a
At 2012-02-07 13:20:43 +0200, pete...@gmx.net wrote:
Should we rename the options and/or add that to the documentation, or is
the new behavior obvious and any new terminology would be too confusing?
I agree there is potential for confusion either way. I tried to come up
with a complete and
On tor, 2012-01-26 at 19:00 +0530, Abhijit Menon-Sen wrote:
At issue are (at least) these three lines from print_unaligned_text in
src/bin/psql/print.c:
358 /* the last record needs to be concluded with a newline
*/
359 if (need_recordsep)
360 fputc('\n',
On Wed, Feb 01, 2012 at 08:19:24PM +0200, Peter Eisentraut wrote:
On tis, 2012-01-17 at 16:46 +0900, Fujii Masao wrote:
When I tested the patch, create ta was converted unexpectedly to
create TABLE
though alter ta was successfully converted to alter table. As far
as I read the patch,
On Tue, Feb 7, 2012 at 8:02 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Feb 01, 2012 at 08:19:24PM +0200, Peter Eisentraut wrote:
On tis, 2012-01-17 at 16:46 +0900, Fujii Masao wrote:
When I tested the patch, create ta was converted unexpectedly to
create TABLE
though alter ta was
On tis, 2012-01-17 at 16:46 +0900, Fujii Masao wrote:
When I tested the patch, create ta was converted unexpectedly to
create TABLE
though alter ta was successfully converted to alter table. As far
as I read the patch,
you seems to have forgotten to change create_or_drop_command_generator()
At 2012-01-14 14:23:49 +0200, pete...@gmx.net wrote:
Inspired by this question http://stackoverflow.com/questions/6857265 I
have implemented a way to set the psql record and field separators to
a zero byte (ASCII NUL character).
Since this patch is in the commitfest, I had a look at it.
I
On Mon, Jan 23, 2012 at 5:28 PM, Dominik Bylica dominik2c...@gmail.com wrote:
Hello.
It's probably not the right place to write, but I guess you are there to
take care of it.
When I was creating a trigger with command like:
create trigger asdf before update on beginninOfTheNameOfMyTable...
Excerpts from Noah Misch's message of sáb ene 14 12:40:02 -0300 2012:
It has bothered me that psql's \copy ignores the ON_ERROR_ROLLBACK setting.
Only SendQuery() takes note of ON_ERROR_ROLLBACK, and \copy, like all
backslash commands, does not route through SendQuery(). Looking into this
On Wed, Jan 18, 2012 at 06:28, Noah Misch n...@leadboat.com wrote:
On Tue, Jan 17, 2012 at 04:01:23PM +0100, Magnus Hagander wrote:
Thus - if I were to change psql to output timing on failed queries as
well, will anybody object? ;)
+1
Done and applied.
--
Magnus Hagander
Me:
On Tue, Jan 17, 2012 at 10:01 AM, Magnus Hagander mag...@hagander.net wrote:
Right now, psql \timing output only gives output for successful
queries. Is there any actual reason for this, or just a it happened?
In particular,I just had a very long run of a CREATE UNIQUE INDEX fail
pretty far
On Tue, Jan 17, 2012 at 04:01:23PM +0100, Magnus Hagander wrote:
Thus - if I were to change psql to output timing on failed queries as
well, will anybody object? ;)
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Jan 12, 2012 at 5:29 AM, Peter Eisentraut pete...@gmx.net wrote:
In psql, the tab completion always converts key words to upper case. In
practice, I and I think most users type in lower case. So then you end
up with commands looking like this:
= alter TABLE foo add CONSTRAINT bar
2012/1/11 Peter Eisentraut pete...@gmx.net:
In psql, the tab completion always converts key words to upper case. In
practice, I and I think most users type in lower case. So then you end
up with commands looking like this:
= alter TABLE foo add CONSTRAINT bar check (a 0);
To address
On Mon, Dec 12, 2011 at 21:04, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote:
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander mag...@hagander.net wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote:
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the output in the query output channel controlled
by \o, and not just the
On fre, 2011-12-09 at 13:44 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
The problem is, this breaks the regression tests, because first the
actual output changes, and second the line numbers get included, which
will create a mess every time you edit a test. Not sure
On lör, 2011-11-26 at 22:36 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql foo.sql does not. I
Peter Eisentraut pete...@gmx.net writes:
The problem is, this breaks the regression tests, because first the
actual output changes, and second the line numbers get included, which
will create a mess every time you edit a test. Not sure whether we can
work around that. Ideas?
Ugh, that's
On 11/28/2011 09:19 PM, Josh Kupershmidt wrote:
Other than those small gripes, the patch looks fine. Attached is an
updated version to save you some keystrokes.
Thanks. Committed.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On lör, 2011-11-26 at 22:36 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql foo.sql does not. I
On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut pete...@gmx.net wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql foo.sql does
On Mon, Nov 28, 2011 at 8:10 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut pete...@gmx.net wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
Naysayers can always make a case for backwards-compatibility, or not
breaking the scripts written with the existing behaviour in mind.
I'm having a hard time imagining how this could break anything. What
scenario did
On Mon, Nov 28, 2011 at 8:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
Naysayers can always make a case
Should've added that I'm not one of them :)
+1 from me on the improvement.
for
Excerpts from Peter Eisentraut's message of sáb nov 26 17:36:15 -0300 2011:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql
On Sat, 26 Nov 2011 22:36:15 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql foo.sql does not. I suggest we
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan and...@dunslane.net wrote:
Also, should the malloc() of newval just use pg_malloc() instead?
Yes, also done.
This bit is unnecessary, since pg_malloc() takes care of the error handling:
+ if (!newval)
+
2011/11/29 Peter Eisentraut pete...@gmx.net:
There was a question recently on a user list about how to configure an
editor to handle psql's editor temp files as SQL files. While this is
doable with an advanced editor by reverse-engineering the file pattern
than psql uses, it would be easier
Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Nov 21, 2011 at 2:30 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Nov 21, 2011 at 1:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Argh. ?The root of the problem here seems to be that
On 11/20/2011 11:07 AM, Josh Kupershmidt wrote:
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstanand...@dunslane.net wrote:
Updated patch is attached - adding to Nov commitfest.
Review of the v2 patch:
* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
Robert Haas wrote:
Argh. The root of the problem here seems to be that
join_path_components() feels entitled to arbitrarily insert a pathname
separator at the front of the output string even if its first input
didn't begin with one originally. Lame!
The attached patch fixes this report, I
On Mon, Nov 21, 2011 at 1:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Argh. The root of the problem here seems to be that
join_path_components() feels entitled to arbitrarily insert a pathname
separator at the front of the output string even if its first input
didn't
Robert Haas wrote:
On Mon, Nov 21, 2011 at 1:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Argh. ?The root of the problem here seems to be that
join_path_components() feels entitled to arbitrarily insert a pathname
separator at the front of the output string even if its
On Mon, Nov 21, 2011 at 2:30 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Nov 21, 2011 at 1:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Argh. ?The root of the problem here seems to be that
join_path_components() feels entitled to arbitrarily
Robert Haas wrote:
On Mon, Nov 21, 2011 at 2:30 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Nov 21, 2011 at 1:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Argh. ?The root of the problem here seems to be that
join_path_components() feels
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan and...@dunslane.net wrote:
Updated patch is attached - adding to Nov commitfest.
Review of the v2 patch:
* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
some tab characters being used in psql-ref.sgml where
On Tue, Nov 15, 2011 at 6:54 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Commit c7f23494c1103f87bcf1ef7cbfcd626e73edb337 editorialized a bit on
Gurjeet Singh's patch to implement \ir for psql, particularly in
process_file(). Unfortunately, it looks like it broke the common case
of loading a
2011/11/13 Tomas Vondra t...@fuzzy.cz:
but recalling it from the query buffer results in
ERROR: Corrupt ascii-armor
I've noticed this on 9.1 but 9.2devel behaves exactly the same. I'm
using 64-bit Linux with UTF8, nothing special.
It looks like the problem is that the original has a blank
On Tue, Nov 08, 2011 at 06:36:52AM +0200, Peter Eisentraut wrote:
Here is an updated patch that addresses all the issues you pointed out.
Looks ready to me. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On lör, 2011-11-05 at 12:26 -0400, Noah Misch wrote:
On Sat, Nov 05, 2011 at 04:53:56PM +0200, Peter Eisentraut wrote:
On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote:
For \pset format wrapped, we only use $COLUMNS when the output is a
tty. I'm thinking it's best, although not
On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote:
For \pset format wrapped, we only use $COLUMNS when the output is a
tty. I'm thinking it's best, although not terribly important, to
apply the same rule to this feature.
I think it does work that way. There is only one place where the
On Sat, Nov 05, 2011 at 04:53:56PM +0200, Peter Eisentraut wrote:
On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote:
For \pset format wrapped, we only use $COLUMNS when the output is a
tty. I'm thinking it's best, although not terribly important, to
apply the same rule to this feature.
On Tue, Nov 01, 2011 at 06:22:47AM +0200, Peter Eisentraut wrote:
I 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
On 17 December 2010 22: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
Sounds like a very good idea.
--
Peter Geoghegan
On 09/26/2011 05:16 PM, Andrew Dunstan wrote:
On 09/26/2011 05:07 PM, Jeff Janes wrote:
But in any case, considering that we are both wondering if it works on
Windows, I think that argues that an automatic regression test would
be very handy.
I think an automated test should be
I have not tried the patch (yet), but Informix'sl dbacess would do about
the same - and it's something I really missed.
Jan
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Peter Eisentraut pete...@gmx.net writes:
Here is a finalized patch for this. The first hunk of the patch is the
documentation change, so you can see there how it's supposed to work.
Let me know what you think.
+1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise,
I 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.
Here is a finalized patch for this. The first hunk of
2011/10/21 Andrew Dunstan andrew.duns...@pgexperts.com:
A few months ago, I blogged about the difficulty of getting psql to put a
bytea datum into a file. See
http://people.planetpostgresql.org/andrew/index.php?/archives/196-Clever-trick-challenge.html.
Today I ran into the problem again, and
On 10/21/2011 02:44 PM, Pavel Stehule wrote:
2011/10/21 Andrew Dunstanandrew.duns...@pgexperts.com:
A few months ago, I blogged about the difficulty of getting psql to put a
bytea datum into a file. See
2011/10/21 Andrew Dunstan andrew.duns...@pgexperts.com:
On 10/21/2011 02:44 PM, Pavel Stehule wrote:
2011/10/21 Andrew Dunstanandrew.duns...@pgexperts.com:
A few months ago, I blogged about the difficulty of getting psql to put a
bytea datum into a file. See
On 10/21/2011 02:51 PM, Pavel Stehule wrote:
2011/10/21 Andrew Dunstanandrew.duns...@pgexperts.com:
On 10/21/2011 02:44 PM, Pavel Stehule wrote:
2011/10/21 Andrew Dunstanandrew.duns...@pgexperts.com:
A few months ago, I blogged about the difficulty of getting psql to put a
bytea datum into a
Pavel Stehule pavel.steh...@gmail.com writes:
2011/10/21 Andrew Dunstan andrew.duns...@pgexperts.com:
On 10/21/2011 02:44 PM, Pavel Stehule wrote:
isn't better to fix current tools to work well with bytea?
Such as?
some like
\copy ... to foo.bin format binary
No, because COPY BINARY will
2011/10/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/10/21 Andrew Dunstan andrew.duns...@pgexperts.com:
On 10/21/2011 02:44 PM, Pavel Stehule wrote:
isn't better to fix current tools to work well with bytea?
Such as?
some like
\copy ... to foo.bin
On 10/21/2011 04:43 PM, Pavel Stehule wrote:
What I don't like about Andrew's proposal is that it seems rather
limited. Why bytea in particular? Text chunks could probably also use
a direct output method. And what about input?
Could we do anything with a notion of a COPY RAW mode, that
On Fri, Oct 21, 2011 at 7:24 AM, Richard Huxton d...@archonet.com wrote:
It looks like \copy is just passing the text of the query unadjusted to
COPY. I get a syntax error on :x with the \copy below on both 9.0 and
9.1
=== test script ===
\set x '''HELLO'''
-- Works
\echo :x
-- Works
\o
Andrew Dunstan andrew.duns...@pgexperts.com writes:
I also think this is really just a psql issue. Most other clients (e.g.
a perl DBD::Pg client) will have no trouble handling all this now.
Well, that's debatable, and in any case I think you'd find it will be
easier to push this into COPY
On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan and...@dunslane.net wrote:
On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
[need way to show current values]
\! echo $foo
(which is how I tested the patch, of course)
Ah, right. IMO it'd be helpful to mention that echo example in
On Mon, Sep 26, 2011 at 12:07 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan and...@dunslane.net wrote:
On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
[need way to show current values]
\! echo $foo
(which is how I tested the patch,
On 09/26/2011 05:07 PM, Jeff Janes wrote:
But in any case, considering that we are both wondering if it works on
Windows, I think that argues that an automatic regression test would
be very handy.
I think an automated test should be possible. Something like:
\setenv PGFOO blurfl
\!
On Thu, Sep 15, 2011 at 7:46 AM, Andrew Dunstan and...@dunslane.net wrote:
On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote:
As discussed, patch attached.
this time with patch.
Hi Andrew,
A description of the \setenv command should show up in the output of \?.
Should there be a
On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote:
As discussed, patch attached.
this time with patch.
setenv.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan and...@dunslane.net wrote:
this time with patch.
I think help.c should document the \setenv command. And a link from
the Environment section[1] of psql's doc page to the section about
\setenv might help too.
The existing \set command lists all
On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan and...@dunslane.net
wrote:
this time with patch.
I think help.c should document the \setenv command. And a link from
the Environment section[1] of psql's doc page to the section about
On 09/11/2011 11:43 PM, Robert Haas wrote:
Second, I'd like to be able to set a minimum number of lines below which the
pager would not be used, something like:
\pset pagerminlines 200
Thoughts?
Gee, why do I feel like we have something like this already?
We do? We control columns,
On mån, 2011-09-12 at 05:26 -0400, Andrew Dunstan wrote:
On 09/11/2011 11:43 PM, Robert Haas wrote:
Second, I'd like to be able to set a minimum number of lines below which
the
pager would not be used, something like:
\pset pagerminlines 200
Thoughts?
Gee, why do I feel
On 09/12/2011 08:39 AM, Peter Eisentraut wrote:
On mån, 2011-09-12 at 05:26 -0400, Andrew Dunstan wrote:
On 09/11/2011 11:43 PM, Robert Haas wrote:
Second, I'd like to be able to set a minimum number of lines below which the
pager would not be used, something like:
\pset pagerminlines
On mån, 2011-09-12 at 09:01 -0400, Andrew Dunstan wrote:
On 09/12/2011 08:39 AM, Peter Eisentraut wrote:
On mån, 2011-09-12 at 05:26 -0400, Andrew Dunstan wrote:
On 09/11/2011 11:43 PM, Robert Haas wrote:
Second, I'd like to be able to set a minimum number of lines below which
the
On Sun, Sep 11, 2011 at 2:58 PM, Andrew Dunstan and...@dunslane.net wrote:
Here's a couple of ideas I had recently about making psql a bit more user
friendly.
First, it would be useful to be able to set pager options and possibly other
settings, so my suggestion is for a \setenv command that
On fre, 2011-08-12 at 16:14 -0400, Robert Haas wrote:
On Fri, Aug 12, 2011 at 4:11 PM, Peter Eisentraut pete...@gmx.net wrote:
A table is either a base table, a derived table, a transient table, or
a viewed table. (SQL/MED adds foreign table.)
Just FYI.
Base table seems clear enough,
On Sat, Aug 13, 2011 at 1:56 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-08-12 at 16:14 -0400, Robert Haas wrote:
On Fri, Aug 12, 2011 at 4:11 PM, Peter Eisentraut pete...@gmx.net wrote:
A table is either a base table, a derived table, a transient table, or
a viewed table.
701 - 800 of 1586 matches
Mail list logo
