On Wed, Jul 9, 2014 at 9:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Barring any objection, I will commit this patch except tab-completion
part.
Committed.
It can be a second discussion, but I am thinking so anywhere when we can use
autocomplete, then we should it - Although it
On Mon, Jun 30, 2014 at 8:33 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2014-06-30 13:01 GMT+02:00 Abhijit Menon-Sen a...@2ndquadrant.com:
At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
+ para
+ Print a failed SQL commands to standard error output. This is
On 26 June 2014 11:53, Samrat Revagade Wrote:
I am sending updated patch - buggy statement is printed via more logical
psql_error function instead printf
Thank you for updating patch, I really appreciate your efforts.
Now, everything is good from my side.
* it apply cleanly to the current
2014-06-30 8:17 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
On 26 June 2014 11:53, Samrat Revagade Wrote:
I am sending updated patch - buggy statement is printed via more
logical psql_error function instead printf
Thank you for updating patch, I really appreciate your efforts.
On 30 June 2014 12:24, Pavel Stehule Wrote:
I have reviewed this patch. Please find my review comments below:
1. Command start-up option (e.g. -a/--echo-all for --ECHO=all), for new
functionality is not provided.
all not options entered via psql variables has psql option and psql comment.
2014-06-30 11:20 GMT+02:00 Rajeev rastogi rajeev.rast...@huawei.com:
On 30 June 2014 12:24, Pavel Stehule Wrote:
I have reviewed this patch. Please find my review comments below:
1. Command start-up option (e.g. -a/--echo-all for --ECHO=all), for
new functionality is not provided.
At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
+ para
+ Print a failed SQL commands to standard error output. This is
+ equivalent to setting the variable varnameECHO/varname to
+ literalerrors/literal.
No a, just Print failed SQL commands ….
-
2014-06-30 13:01 GMT+02:00 Abhijit Menon-Sen a...@2ndquadrant.com:
At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
+ para
+ Print a failed SQL commands to standard error output. This is
+ equivalent to setting the variable varnameECHO/varname to
+
I am sending updated patch - buggy statement is printed via more logical
psql_error function instead printf
Thank you for updating patch, I really appreciate your efforts.
Now, everything is good from my side.
* it apply cleanly to the current git master
* includes necessary docs
* I think It
2014-06-26 8:22 GMT+02:00 Samrat Revagade revagade.sam...@gmail.com:
I am sending updated patch - buggy statement is printed via more logical
psql_error function instead printf
Thank you for updating patch, I really appreciate your efforts.
Now, everything is good from my side.
* it apply
Hi Pavel,
After applying patch, on error condition it displays error message two
times as follows:
ERROR: column abc does not exist at character 23
STATEMENT: insert into ax
values(abc);
psql:a.sql:7: ERROR: column abc does not exist
LINE 2: values(abc);
user may confuse because of repeated
2014-06-25 12:32 GMT+02:00 Samrat Revagade revagade.sam...@gmail.com:
Hi Pavel,
After applying patch, on error condition it displays error message two
times as follows:
ERROR: column abc does not exist at character 23
STATEMENT: insert into ax
values(abc);
psql:a.sql:7: ERROR: column
ECHO_HIDDEN?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello
updated patch - only one change: query is prefixed by QUERY:
current state:
[pavel@localhost ~]$ src/postgresql/src/bin/psql/psql postgres -q -f
data.sql
psql:data.sql:6: ERROR: value too long for type character varying(3)
Show only errors mode:
[pavel@localhost ~]$
On 6/4/14, 11:54 AM, Pavel Stehule wrote:
updated patch - only one change: query is prefixed by QUERY:
In the backend server log, this is called STATEMENT: .
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2014-06-04 18:16 GMT+02:00 Peter Eisentraut pete...@gmx.net:
On 6/4/14, 11:54 AM, Pavel Stehule wrote:
updated patch - only one change: query is prefixed by QUERY:
In the backend server log, this is called STATEMENT: .
good idea
updated patch
Pavel
commit
On Fri, May 16, 2014 at 2:03 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Hi all,
Are there some reason to don't show the tablespace size in the \db+ psql
command?
The attached patch show tablespace size in \db+ psql command.
Regards,
--
Fabrízio de Royes Mello
Andreas,
* Andreas Karlsson (andr...@proxel.se) wrote:
When benchmarking an application I got annoyed at how basic the tab
completion for ALTER TABLE ... DISABLE/ENABLE TRIGGER and DROP
TRIGGER is. So here is a patch improving the tab completion around
triggers. For consistency I have also
On Thu, Apr 10, 2014 at 08:05:11PM -0400, Bruce Momjian wrote:
On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status
On Wed, Apr 9, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's sorta my concern. I mean, right now
On Thu, Apr 10, 2014 at 12:23:40PM -0400, Robert Haas wrote:
What might make more sense is this:
if ((tableinfo.relkind == 'r' || tableinfo.relkind == 'm')
/*
* No need to display default values; we already display a
* REPLICA IDENTITY
If it's conditional I think when it matches a guc is too hard for users
to use.
I think say nothing if oids are off and say something of their on would
be fine. It would result in clutter for users which oids on by default but
that's a non default setting.
And the consequences of having oids on
On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote:
If it's conditional I think when it matches a guc is too hard for users to
use.
Yes, we gave up on having the OID display match the GUC; we just
display something if and only if it oids are present.
Robert is talking about the
On Tue, Apr 1, 2014 at 10:45:29AM -0700, Jeff Janes wrote:
I am suggesting it for at least some other things. I'm rather aggrieved that
\d+ without argument shows you the size and the description/comment for every
table, but \d+ foo does not show you the size and description/comment of the
On Thu, Apr 10, 2014 at 01:10:35PM -0400, Bruce Momjian wrote:
On Thu, Apr 10, 2014 at 01:05:32PM -0400, Greg Stark wrote:
If it's conditional I think when it matches a guc is too hard for users to
use.
Yes, we gave up on having the OID display match the GUC; we just
display something if
Bruce Momjian br...@momjian.us writes:
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when present.
Yeah, I was wondering about that too. If part of the
On Thu, Apr 10, 2014 at 07:58:55PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
It also has changed the OID status to only display if it exists. One
question that came up with Robert is whether OID status should appear
for \d as well, now that is only shows up when
On Wed, Apr 9, 2014 at 01:02:05AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's sorta my concern. I mean, right now we've got people
saying what the heck is a replica identity?. But, if the logical
decoding stuff becomes popular, as I hope it will, that's
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's sorta my concern. I mean, right now we've got people
saying what the heck is a replica identity?. But, if the logical
decoding stuff becomes popular, as I hope it will,
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's sorta my concern. I mean, right now we've got people
saying what the heck is a replica identity?. But, if
On 2014-04-09 11:42:32 -0400, Bruce Momjian wrote:
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's sorta my concern. I mean, right now we've got people
On Tue, Apr 1, 2014 at 01:36:02PM -0400, Robert Haas wrote:
Although I agree with the general principle, I'm skeptical in this
case. There are a bunch of table-level options, and I don't think
it's very reasonable to expect that users are going to remember which
ones are going to be
Bruce Momjian br...@momjian.us writes:
If we ignore backward compatibility, then Has OIDs and Identity
Replica are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the mention of OIDs or Identity Replica than will
On Tue, Apr 8, 2014 at 05:29:45PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
If we ignore backward compatibility, then Has OIDs and Identity
Replica are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Bruce Momjian br...@momjian.us writes:
If we ignore backward compatibility, then Has OIDs and Identity
Replica are similar. One thing that strongly (for me) supports not
always printing them is that I expect more people will be confused by
the
On Tue, Apr 8, 2014 at 5:37 PM, Bruce Momjian br...@momjian.us wrote:
On Tue, Apr 8, 2014 at 05:29:45PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
If we ignore backward compatibility, then Has OIDs and Identity
Replica are similar. One thing that strongly (for me)
Robert Haas robertmh...@gmail.com writes:
Well, that's sorta my concern. I mean, right now we've got people
saying what the heck is a replica identity?. But, if the logical
decoding stuff becomes popular, as I hope it will, that's going to be
an important thing for people to adjust, and the
On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Mar 29, 2014 at 06:33:39PM -0400, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are you saying most people like Has OIDs: yes, or the idea
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of Replica Identity
patch (which is how it was originally coded anyway). The attached patch
matches Tom's suggestion of displaying the same OID text, just
conditionally.
Seeing
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of Replica Identity
patch (which is how it was originally coded anyway). The attached patch
matches Tom's
Bruce Momjian br...@momjian.us writes:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
Frankly, I think this is all completely wrong-headed. \d+ should
display *everything*. That's what the + means, isn't it? Coming up
with complex rules for which things get shown and which
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything, you have to look at the system
tables.
I don't really agree with
On Tue, Apr 1, 2014 at 12:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything,
On 2014-04-01 13:36:02 -0400, Robert Haas wrote:
I can't accept that tinkering with that is
reducing clutter in any meaningful way; it's just change for the sake
of change.
+1
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
On Tue, Apr 1, 2014 at 8:42 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of Replica Identity
patch (which is how it was originally coded anyway). The attached
patch
matches Tom's
On Sat, Mar 29, 2014 at 06:33:39PM -0400, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are you saying most people like Has OIDs: yes, or the idea of just
displaying _a_ line if there are OIDs? Based on
On Mar 28, 2014, at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
We
On Fri, Mar 28, 2014 at 03:53:32PM -0300, Fabrízio de Royes Mello wrote:
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it
Bruce Momjian wrote
On Fri, Mar 28, 2014 at 03:53:32PM -0300, Fabrízio de Royes Mello wrote:
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane lt;
tgl@.pa
gt; wrote:
Bruce Momjian lt;
bruce@
gt; writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was
On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
As my belief is that 99% of the uses of \d are for human consumption
(because machines should in most cases hit the catalogs directly) then
strictly displaying Includes OIDs when appropriate has my +1.
Uses of \d+ in regression
On 03/29/2014 04:49 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
As my belief is that 99% of the uses of \d are for human consumption
(because machines should in most cases hit the catalogs directly) then
strictly displaying Includes OIDs when
On Sat, Mar 29, 2014 at 05:10:49PM -0400, Andrew Dunstan wrote:
On 03/29/2014 04:49 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
As my belief is that 99% of the uses of \d are for human consumption
(because machines should in most cases hit the
On 03/29/2014 06:10 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 05:10:49PM -0400, Andrew Dunstan wrote:
On 03/29/2014 04:49 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
As my belief is that 99% of the uses of \d are for human consumption
Bruce Momjian br...@momjian.us writes:
Are you saying most people like Has OIDs: yes, or the idea of just
displaying _a_ line if there are OIDs? Based on default_with_oids,
perhaps we should display With OIDs.
I agree it is no unanimous. I am curious how large the majority has to
be to
On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are you saying most people like Has OIDs: yes, or the idea of just
displaying _a_ line if there are OIDs? Based on default_with_oids,
perhaps we should display With OIDs.
I agree it is no
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
* Euler Taveira (eu...@timbira.com.br) wrote:
On 27-03-2014 10:15, Bruce Momjian wrote:
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
We seem to be split on the idea of having Has OIDs display only when
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
I believe Bruce was suggesting to show it when it is set to *not* the
default, which strikes me as perfectly reasonable.
We seem to be split on
On 27-03-2014 10:15, Bruce Momjian wrote:
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Column | Type | Modifiers | Storage | Stats target | Description
* Euler Taveira (eu...@timbira.com.br) wrote:
On 27-03-2014 10:15, Bruce Momjian wrote:
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Column | Type | Modifiers | Storage | Stats target |
Bruce Momjian wrote
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Column | Type | Modifiers | Storage | Stats target | Description
On 03/27/2014 04:43 PM, David Johnston wrote:
Bruce Momjian wrote
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Column | Type | Modifiers | Storage | Stats target | Description
On 2014-03-27 09:15:52 -0400, Bruce Momjian wrote:
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Column | Type | Modifiers | Storage | Stats target | Description
On 3/22/14, 11:26 AM, Jim Nasby wrote:
On 3/21/14, 4:54 PM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
There is no way for psql to handle that case though unless you'd strip
*all* BOMs encountered. Compounding this problem is that there's no
practical way AFAIK to send multiple
On 03/24/2014 02:50 PM, Jim Nasby wrote:
On 3/22/14, 11:26 AM, Jim Nasby wrote:
On 3/21/14, 4:54 PM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
There is no way for psql to handle that case though unless you'd strip
*all* BOMs encountered. Compounding this problem is that
Andrew Dunstan and...@dunslane.net writes:
I suspect suspect trying to do this in the parser will be quite messy.
This needs to happen before the input is converted to the server
encoding, I think.
Indeed --- what if the server isn't using utf8 internally?
And a larger point is that the
On Mon, Mar 24, 2014 at 2:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I suspect suspect trying to do this in the parser will be quite messy.
This needs to happen before the input is converted to the server
encoding, I think.
Indeed --- what if the
On Mon, Mar 24, 2014 at 2:37 PM, Merlin Moncure mmonc...@gmail.com wrote:
psql -1 already requires '-f' to work
actually, it doesn't. this was fixed recently.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 3/24/14, 1:59 PM, Andrew Dunstan wrote:
It occurs to me that we're going about this the wrong way...
The error here isn't being generated by psql; it's generated by the backend. In
the context of a statement (and not, say, a COPY command).
So instead of trying to handle this on the psql
Jim Nasby j...@nasby.net writes:
Wait... I thought that was one of the objections... that we wanted to
leave a BOM in something like a COPY untouched?
I think most of us are okay with stripping a BOM that appears at the
*beginning* of a text file (assuming there's reason to believe the file
is
Just a quick comment on this. Yes, pgAdmin always added a BOM in every
SQL files it wrote.
From
http://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom:
According to the Unicode standard, the BOM for UTF-8 files is not recommended:
2.6 Encoding
The code would probably be pretty trivial, *if* we had consensus on
what the behavior ought to be. I'm not sure if we do. People who
only use Unicode would probably like it if BOMs were unconditionally
swallowed, whether or not psql thinks the client_encoding is UTF8.
(And I seem to recall
On 03/24/2014 08:28 PM, Tatsuo Ishii wrote:
The code would probably be pretty trivial, *if* we had consensus on
what the behavior ought to be. I'm not sure if we do. People who
only use Unicode would probably like it if BOMs were unconditionally
swallowed, whether or not psql thinks the
On 03/25/2014 02:50 AM, Jim Nasby wrote:
So instead of trying to handle this on the psql side[1], I think we need
to handle it in the backend; specifically in the parser. Is there an
easy way to get the parser to ignore the BOM character in the context of
commands (but not in strings)?
I
On 03/25/2014 07:05 AM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
Wait... I thought that was one of the objections... that we wanted to
leave a BOM in something like a COPY untouched?
I think most of us are okay with stripping a BOM that appears at the
*beginning* of a text file
On Sat, 2014-03-22 at 11:23 -0500, Jim Nasby wrote:
On 3/21/14, 8:13 PM, David E. Wheeler wrote:
On Mar 21, 2014, at 2:16 PM, Andrew Dunstan and...@dunslane.net wrote:
Surely if it were really a major annoyance, someone would have sent code
to fix it during the last 4 years and more
On Mar 23, 2014, at 8:03, Guillaume Lelarge guilla...@lelarge.info wrote:
Just a quick comment on this. Yes, pgAdmin always added a BOM in every
SQL files it wrote.
From
http://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom:
According to the Unicode
On 3/21/14, 8:13 PM, David E. Wheeler wrote:
On Mar 21, 2014, at 2:16 PM, Andrew Dunstan and...@dunslane.net wrote:
Surely if it were really a major annoyance, someone would have sent code to fix
it during the last 4 years and more since the above.
I suspect it's a minor annoyance :-)
But
On 3/21/14, 4:54 PM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
There is no way for psql to handle that case though unless you'd strip
*all* BOMs encountered. Compounding this problem is that there's no
practical way AFAIK to send multiple file to psql via single command
line
On Fri, Mar 21, 2014 at 4:02 PM, Jim Nasby j...@nasby.net wrote:
See http://www.postgresql.org/message-id/4afeab39.3000...@dunslane.net
This is still broken as of fairly recent HEAD; any objections to adding it to
TODO?
Agreed: this is a major annoyance.
merlin
--
Sent via pgsql-hackers
On 03/21/2014 05:06 PM, Merlin Moncure wrote:
On Fri, Mar 21, 2014 at 4:02 PM, Jim Nasby j...@nasby.net wrote:
See http://www.postgresql.org/message-id/4afeab39.3000...@dunslane.net
This is still broken as of fairly recent HEAD; any objections to adding it to
TODO?
Agreed: this is a major
Andrew Dunstan and...@dunslane.net writes:
Surely if it were really a major annoyance, someone would have sent code
to fix it during the last 4 years and more since the above.
The code would probably be pretty trivial, *if* we had consensus on
what the behavior ought to be. I'm not sure if we
On Fri, Mar 21, 2014 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be okay with swallowing a leading BOM if and only if client encoding
is UTF8. This should apply to any file psql reads, whether script or
data.
Yeah. The one case that doesn't solve is:
cat f1.sql f2.sql | psql ...
Merlin Moncure mmonc...@gmail.com writes:
There is no way for psql to handle that case though unless you'd strip
*all* BOMs encountered. Compounding this problem is that there's no
practical way AFAIK to send multiple file to psql via single command
line invocation. If you pass multiple -f
On Mar 21, 2014, at 2:16 PM, Andrew Dunstan and...@dunslane.net wrote:
Surely if it were really a major annoyance, someone would have sent code to
fix it during the last 4 years and more since the above.
I suspect it's a minor annoyance :-)
But by all means add it to the TODO list if
On Sat, Mar 1, 2014 at 8:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I was asked, how can be showed only failed queries in psql.
I am thinking, so it is not possible now. But implementation is very
simple
What do you think about it?
bash-4.1$ psql postgres -v ECHO=error -f
2014-03-04 6:35 GMT+01:00 Fabrízio de Royes Mello fabriziome...@gmail.com:
On Sat, Mar 1, 2014 at 8:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I was asked, how can be showed only failed queries in psql.
I am thinking, so it is not possible now. But implementation
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
As others, I am concerned about people being confused when funny-looking
trigger names suddenly appearing when you disable all table triggers.
What I ended up doing is to create a user and internal section when
displaying
On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
As others, I am concerned about people being confused when funny-looking
trigger names suddenly appearing when you disable all table triggers.
What I ended up doing is to
On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote:
On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
As others, I am concerned about people being confused when funny-looking
trigger names suddenly appearing when
On 2014-02-24 13:16:39 -0500, Bruce Momjian wrote:
On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote:
On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
As others, I am concerned about people being confused when
On Mon, Feb 24, 2014 at 3:23 PM, Andres Freund and...@2ndquadrant.com
wrote:
Thanks. It'd have been nice tho, to mention Fabrízio in the commit
message as the patch's author.
Uh, I was thinking of that, but I basically rewrote the patch from
scratch and changed its visible behavior, so
On Mon, Feb 24, 2014 at 07:23:50PM +0100, Andres Freund wrote:
On 2014-02-24 13:16:39 -0500, Bruce Momjian wrote:
On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote:
On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian
On Thu, Nov 21, 2013 at 11:59:51PM -0200, Fabrízio de Royes Mello wrote:
On Fri, Oct 25, 2013 at 3:37 PM, fabriziomello fabriziome...@gmail.com
wrote:
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
--On 18. September 2013 13:52:29
On Thu, Feb 13, 2014 at 12:04 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, Nov 21, 2013 at 11:59:51PM -0200, Fabrízio de Royes Mello wrote:
On Fri, Oct 25, 2013 at 3:37 PM, fabriziomello fabriziome...@gmail.com
wrote:
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
On
2013/11/26 Sawada Masahiko sawada.m...@gmail.com
Hi all,
When I execute query which contains error, the server returns error
with line number.
ERROR: relation hoge does not exist
LINE 35: hoge;
But when query is long, I was not sure the location where I wrote wrong
SQL.
Does the psql
On 11/26/13 1:05 PM, Sawada Masahiko wrote:
When I execute query which contains error, the server returns error
with line number.
ERROR: relation hoge does not exist
LINE 35: hoge;
But when query is long, I was not sure the location where I wrote wrong SQL.
Does the psql have option which
On Tue, Nov 26, 2013 at 9:23 PM, Marko Tiikkaja ma...@joh.to wrote:
On 11/26/13 1:05 PM, Sawada Masahiko wrote:
When I execute query which contains error, the server returns error
with line number.
ERROR: relation hoge does not exist
LINE 35: hoge;
But when query is long, I was not sure
2013/11/26 Sawada Masahiko sawada.m...@gmail.com
On Tue, Nov 26, 2013 at 9:23 PM, Marko Tiikkaja ma...@joh.to wrote:
On 11/26/13 1:05 PM, Sawada Masahiko wrote:
When I execute query which contains error, the server returns error
with line number.
ERROR: relation hoge does not exist
501 - 600 of 1586 matches
Mail list logo
