On Tue, Apr 21, 2009 at 09:26:13AM -0700, Joshua D. Drake wrote:
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
On Tue, Apr 21, 2009 at 09:33:26AM -0700, David Fetter wrote:
On Tue, Apr 21, 2009 at 09:26:13AM -0700, Joshua D. Drake wrote:
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]
David Fetter wrote:
Oh, and I forgot to send some error-handling and cleanup code per
Alvaro. Please find attached. :)
Declarations before code please.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via
Kevin Grittner kevin.gritt...@wicourts.gov writes:
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
Yeah.
On Tue, Apr 21, 2009 at 01:04:44PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Oh, and I forgot to send some error-handling and cleanup code per
Alvaro. Please find attached. :)
Declarations before code please.
Fixed patch attached.
Cheers,
David.
--
David Fetter
Alvaro Herrera wrote:
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+]
David Fetter wrote:
On Tue, Apr 21, 2009 at 01:04:44PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Oh, and I forgot to send some error-handling and cleanup code per
Alvaro. Please find attached. :)
Declarations before code please.
Fixed patch attached.
Applied.
--
-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 to do [][] like Alvaro suggested.
David Fetter wrote:
Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
This help line:
+ fprintf(output, _( \\df[S+] [PATTERN] list functions. Add a, n,
t, w for aggregate, normal, trigger, window\n));
needs shortening to below 80 chars (or maybe
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
This help line:
+ fprintf(output, _( \\df[S+] [PATTERN] list functions. Add a, n,
t, w for aggregate,
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
Interesting question.
This help line:
+ fprintf(output, _( \\df[S+] [PATTERN] list functions. Add a, n,
On Tue, Apr 14, 2009 at 03:18:06PM -0700, David Fetter wrote:
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be better
to make
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 stands for aggregate, add a
/* translator: */ comment.
The translator: comment needs to be in
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 stands for aggregate, add a
David Fetter wrote:
On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote:
The translator: comment needs to be in the line just above the
string.
Is this any better?
Yeah, this one is good (as far as this very minor detail is concerned anyway)
--
Alvaro Herrera
David Fetter da...@fetter.org writes:
On Mon, Apr 13, 2009 at 07:24:31PM -0400, Tom Lane wrote:
I'd go for something like
Type
window
agg
trigger
normal
Or we could spell out aggregate, but that makes the column a
couple of characters wider ...
Done.
I had a second thought about
On Tue, Apr 14, 2009 at 12:35:21PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Mon, Apr 13, 2009 at 07:24:31PM -0400, Tom Lane wrote:
I'd go for something like
Type
window
agg
trigger
normal
Or we could spell out aggregate, but that makes the column a
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be better
to make the aggregate case be aggregate and take the width hit.
Otherwise translators are going to be puzzled when they come across
agg as a
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be
better to make the aggregate case be aggregate and take the
width hit.
David Fetter wrote:
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera 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 stands for aggregate,
add a /*
On Tue, Apr 14, 2009 at 03:04:55PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera 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
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be better
to make the aggregate case be aggregate and take the width hit.
Otherwise
David Fetter da...@fetter.org writes:
Here's a patch that adds a Function Type column to \df while
removing the now-redundant \da.
Removing \da altogether was nowhere in the consensus, or even in the
discussion AFAIR. Also, what is the point of using single-letter
type codes when you've made
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Here's a patch that adds a Function Type column to \df while
removing the now-redundant \da.
1. How does it make it redundant - is there a way to view all
aggregates with \df now?
2. Even if the above is satisfied, I think we need a little
On Mon, Apr 13, 2009 at 07:24:31PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Here's a patch that adds a Function Type column to \df while
removing the now-redundant \da.
Removing \da altogether was nowhere in the consensus, or even in the
discussion AFAIR.
It's back.
Tom Lane wrote:
Well, if they're all in your search_path then plain old \df will do
fine. If they're not in your search path then I think it gets pretty
questionable whether they're user defined in a real sense. It seems
more likely that you've got a pile of modules loaded, and which of
Martin Pihlak wrote:
Tom Lane wrote:
Well, if they're all in your search_path then plain old \df will do
fine. If they're not in your search path then I think it gets pretty
questionable whether they're user defined in a real sense. It seems
more likely that you've got a pile of modules
On Wed, Apr 8, 2009 at 3:49 PM, Bruce Momjian br...@momjian.us wrote:
We already had a huge discussion over 'S' and I think we did as good as
we can. I think we risk overcomplicating the API by adding U, but we
can revisit this in 8.5 once we get more feedback from users.
I think we'll need
Greg Stark st...@enterprisedb.com writes:
On Wed, Apr 8, 2009 at 3:49 PM, Bruce Momjian br...@momjian.us wrote:
We already had a huge discussion over 'S' and I think we did as good as
we can. I think we risk overcomplicating the API by adding U, but we
can revisit this in 8.5 once we get more
Tom Lane escribió:
BTW, I hesitate to mention this and perhaps upset a fragile consensus,
but should we remove the special-case code in \df that tries to hide I/O
functions by excluding functions that take or return cstring? I think
that its value has largely disappeared given the new
Alvaro Herrera wrote:
Tom Lane escribi?:
BTW, I hesitate to mention this and perhaps upset a fragile consensus,
but should we remove the special-case code in \df that tries to hide I/O
functions by excluding functions that take or return cstring? I think
that its value has largely
Bruce Momjian br...@momjian.us writes:
Alvaro Herrera wrote:
Tom Lane escribi?:
BTW, I hesitate to mention this and perhaps upset a fragile consensus,
but should we remove the special-case code in \df that tries to hide I/O
functions by excluding functions that take or return cstring? I
Tom Lane wrote:
I don't find this to be a pressing problem. If the user has lots of
schemas, they probably have lots of objects too, and are unlikely to
need such a thing.
Current behaviour makes it impossible to get a quick overview of all the
user defined objects. And it doesn't really
Martin Pihlak martin.pih...@gmail.com writes:
Tom Lane wrote:
I don't find this to be a pressing problem. If the user has lots of
schemas, they probably have lots of objects too, and are unlikely to
need such a thing.
Current behaviour makes it impossible to get a quick overview of all the
Bruce Momjian wrote:
I have applied a simplified version of your patch, attached, that adds
just a AND line to the query; I was a little concerned that IN
might affect performance, and the macros seemed kind of complicated.
Thanks.
Also, since my patch this morning any pattern will also
Martin Pihlak martin.pih...@gmail.com writes:
Hmm, this is a problem -- \dX *.* now shows all objects, and there is
no way to list only user objects. This is especially a problem if user
objects are scattered in different schemas.
I don't find this to be a pressing problem. If the user has
Attached patch applied, including documentation updates; I think this
is the best we are going to do to balance usability and consistency. I
have removed this as an open 8.4 item.
With this change \dfS and \df * do the same thing; I assume we don't
want to remove the 'S' modifier and tell
Martin Pihlak wrote:
Attached is a patch that modifies psql \dX commands to treat objects
in information_schema as system objects. This prevents them from
showing up in \dX *.* and polluting the user objects list. This is
especially annoying if user objects are in multiple schemas, and
one
Robert Treat wrote:
On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian br...@momjian.us wrote:
Maybe the best we are going to do is to have any pattern supplied to
\d* assume 'S' (include system objects). ?I
Robert Treat wrote:
Actually I find the inconsistency to hurt usability, which is typically what
you get with inconsistent interfaces.
I'm not certain, but I think I would be happier if we did:
\d*user space objects
\d*S include system objects
For those that want system only,
On Sun, Mar 29, 2009 at 1:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now I *have* a user function named sin(), it's not getting called
(which might surprise me if I didn't know there was a conflicting
system function) and \df doesn't show me either one.
I actually was expecting the above
Robert Haas robertmh...@gmail.com writes:
That still has the problem that \df a* is horribly inconsistent with
\df. It might be reasonable to assume that if a name without
wildcards is given to any \d command, it should display whatever
object it finds, user or system - but I can't see doing
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian br...@momjian.us wrote:
Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). I actually have a patch that does
that, attached. (It is from January so might need adjustment.)
That still has
Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). I actually have a patch that does
that, attached. (It is from January so might need adjustment.)
---
Robert Haas
On Mon, Mar 30, 2009 at 10:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
That still has the problem that \df a* is horribly inconsistent with
\df. It might be reasonable to assume that if a name without
wildcards is given to any \d command, it should
Robert Haas wrote:
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian br...@momjian.us wrote:
Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). ?I actually have a patch that does
that, attached. (It is from January so might need
On Mon, Mar 30, 2009 at 10:52 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian br...@momjian.us wrote:
Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). ?I actually have a
Hi,
Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
I think the big question is whether the inconsistency (pattern implies
'S') is worth accepting for greater usability.
My answer is yes, please, definitely, go for it.
We don't need idiot-proof easy to remember semantics, we need useful
On Mon, Mar 30, 2009 at 09:59:41PM +0200, Dimitri Fontaine wrote:
Hi,
Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
I think the big question is whether the inconsistency (pattern implies
'S') is worth accepting for greater usability.
My answer is yes, please, definitely, go for it.
We
On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian br...@momjian.us wrote:
Maybe the best we are going to do is to have any pattern supplied to
\d* assume 'S' (include system objects). ?I actually have a patch that
Robert Haas robertmh...@gmail.com writes:
I think you should reconsider your non-buying of that argument. That
would be really, really annoying for me. Most of the time I want to
look at a user object. But every now and then I want to look at a
system object.
I still think that this
Tom Lane wrote:
I actually was expecting the above example to show me the user function,
which I was then going to rant about being a lie. But the actual
behavior is even worse than that.
There is not anything that is not broken about HEAD's behavior,
and the sooner we admit that the
Bruce Momjian escreveu:
The psql system object display issue has not been completely resolved
for 8.4; see 8.4 open items:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
So what is the proposal? Have U/S/A flags for all commands and have
different system display
Euler Taveira de Oliveira wrote:
Bruce Momjian escreveu:
The psql system object display issue has not been completely resolved
for 8.4; see 8.4 open items:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
So what is the proposal? Have U/S/A flags for all
On Sat, Mar 28, 2009 at 1:25 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Bruce Momjian escreveu:
The psql system object display issue has not been completely resolved
for 8.4; see 8.4 open items:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
So what is
On Sat, Mar 28, 2009 at 4:25 PM, Bruce Momjian br...@momjian.us wrote:
Euler Taveira de Oliveira wrote:
Bruce Momjian escreveu:
The psql system object display issue has not been completely resolved
for 8.4; see 8.4 open items:
Greg Sabino Mullane wrote:
Quick patch to fix the fact that the EXPLAIN ANALYZE VERBOSE is clobbering
tab-completion for ANALYZE VERBOSE.
Thanks.
*** tab-complete.c 24 Feb 2009 10:06:34 - 1.180
--- tab-complete.c 27 Mar 2009 01:29:06 -
***
*** 1627,1633
I find that that particular rule is formatted differently than the
others. It took me a while to figure out how it works.
Yeah, me too, but I was trying to keep my change inline with the local logic, so
to speak. +1 to making it more consistent.
While we're at it, any idea what the logic
Greg Sabino Mullane wrote:
I find that that particular rule is formatted differently than the
others. It took me a while to figure out how it works.
Yeah, me too, but I was trying to keep my change inline with the local logic, so
to speak. +1 to making it more consistent.
Ok, committed with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 12 déc. 08 à 12:58, Peter Eisentraut a écrit :
The current proposed patch allocates the following psql \d commands:
[...]
In an idle second I thought, how about F for foreign, but of
course \dF* is already used for full-text search. We
Dimitri Fontaine wrote:
Le 12 déc. 08 à 12:58, Peter Eisentraut a écrit :
In an idle second I thought, how about F for foreign, but of course
\dF* is already used for full-text search. We could overload the F,
but it might be weird.
Other ideas?
What about \dM prefix, M standing for
Alvaro Herrera wrote:
What about \dM prefix, M standing for MED? It seems free in my 8.3 psql
here.
So \dMf for foreign servers, \dMu for user mappings, etc? That seems good.
I find the mixed case commands somewhat inconvinient -- too easy to make
typing mistakes, also slow to enter. If
Alvaro Herrera alvhe...@commandprompt.com writes:
Dimitri Fontaine wrote:
What about \dM prefix, M standing for MED? It seems free in my 8.3 psql
here.
So \dMf for foreign servers, \dMu for user mappings, etc? That seems good.
I'd suggest e for external. M for management is a pretty
On Fri, Dec 12, 2008 at 08:24:36AM -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Dimitri Fontaine wrote:
What about \dM prefix, M standing for MED? It seems free in my
8.3 psql here.
So \dMf for foreign servers, \dMu for user mappings, etc? That
seems good.
David Fetter wrote:
On Fri, Dec 12, 2008 at 08:24:36AM -0500, Tom Lane wrote:
I'd suggest e for external. M for management is a pretty
useless mnemonic --- what's being managed?
\def, \deu, etc. sound great :)
\dew show foreign-data wrappers
\des show foreign servers
\deu
Alvaro Herrera alvhe...@commandprompt.com writes:
\dew show foreign-data wrappers
\des show foreign servers
\deu show user mappings
Right, but maybe use external rather than foreign in the help
so that people recognize what the mnemonic is.
regards, tom
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
\dew show foreign-data wrappers
\des show foreign servers
\deu show user mappings
I'd prefer external rather than foreign, because new users could
confuse the latter with foreign keys.
--Josh
--
Sent via
For making psql fully scriptable I would think it would be smarter to
embed a full well-supported existing language rather than trying to
invent a new one.
If we do want to to that I would suggest looking at lua which is
intended to be used this way.
greg
On 23 Oct 2008, at 05:45 AM,
On 23 okt 2008, at 00.48, Alvaro Herrera [EMAIL PROTECTED]
wrote:
Josh Berkus wrote:
Hackers,
Just had a feature request from Wheeler, and I don't see why it
shouldn't
go on our todo list.
I think you're asking for more scriptability in psql. Personally I
think that would be a great
2008/10/23 Greg Stark [EMAIL PROTECTED]:
For making psql fully scriptable I would think it would be smarter to embed
a full well-supported existing language rather than trying to invent a new
one.
plpgsql?
regards
Pavel
If we do want to to that I would suggest looking at lua which is
Pavel Stehule wrote:
2008/10/23 Greg Stark [EMAIL PROTECTED]:
For making psql fully scriptable I would think it would be smarter to embed
a full well-supported existing language rather than trying to invent a new
one.
plpgsql?
I think plpgsql is a pretty good example of the sort of disaster
Magnus Hagander wrote:
If you want full scripting, look at pgscript, one of this summers gsoc
projects. It'll ship in the next pgadmin and is also available as a
standalone executable.
Yet another language?
What people asking for psql scriptability really want, in my estimate,
is the
2008/10/23 Peter Eisentraut [EMAIL PROTECTED]:
Magnus Hagander wrote:
If you want full scripting, look at pgscript, one of this summers gsoc
projects. It'll ship in the next pgadmin and is also available as a
standalone executable.
Yet another language?
it is more crazy - pgscript is based
On Wed, Oct 22, 2008 at 04:14:11PM -0700, Joshua Drake wrote:
True enough, but a car doesn't roll without at least four wheels.
I'm not sure I agree: http://en.wikipedia.org/wiki/Image:1885Benz.jpg
(Sorry, I couldn't resist.)
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
Everyone,
What people asking for psql scriptability really want, in my estimate,
is the ability to write SQL plus some control structures anywhere, in
the server, in the client, or so that they don't have to know where.
Commercial vendors have that: Oracle has PL/SQL as server-side language
Josh Berkus wrote:
Hackers,
Just had a feature request from Wheeler, and I don't see why it shouldn't
go on our todo list.
I think you're asking for more scriptability in psql. Personally I
think that would be a great idea, but we need a lot more than what's
being proposed here. We'll
Josh Berkus [EMAIL PROTECTED] writes:
but you can't do
\set myvar Select now()
That's a seriously ridiculous syntax.
If you want something like this, a variant of \g that squirts the
results to a variable instead of a file would be more usable:
no quoting problems and no restriction to a
I think you're asking for more scriptability in psql. Personally I
think that would be a great idea, but we need a lot more than what's
being proposed here. We'll also need loops, conditionals, etc. We've
had patches for those submitted over the years, but one at a time they
are easily
On Wed, 22 Oct 2008 19:06:59 -0400
Robert Haas [EMAIL PROTECTED] wrote:
I think you're asking for more scriptability in psql. Personally I
think that would be a great idea, but we need a lot more than what's
being proposed here. We'll also need loops, conditionals, etc.
We've had
Tom,
If you want something like this, a variant of \g that squirts the
results to a variable instead of a file would be more usable:
no quoting problems and no restriction to a single-line query.
I don't care about syntax, and neither does David, I think. If we use \g
or \o, that's fine
True enough, but a car doesn't roll without at least four wheels.
True, but I'm not sure why we'd need three other wheels to make this
feature roll, or what those three wheels would be. Personally, I
would never write a complicated script in psql rather than perl, but I
can imagine using this
On Wed, 22 Oct 2008 20:43:44 -0400
Robert Haas [EMAIL PROTECTED] wrote:
True enough, but a car doesn't roll without at least four wheels.
True, but I'm not sure why we'd need three other wheels to make this
feature roll, or what those three wheels would be. Personally, I
would never write
So now that we have both agreed with each other, what do we do? :P
Well, the original suggestion was to add it to the TODO list. That
seems reasonable to me.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Joshua Drake [EMAIL PROTECTED] writes:
Robert Haas [EMAIL PROTECTED] wrote:
We can't do anything unless we do everything is a recipe for
failure.
True enough, but a car doesn't roll without at least four wheels.
Perhaps more to the point: you don't have to implement every part of a
set of
Alvaro Herrera [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Hackers,
Just had a feature request from Wheeler, and I don't see why it shouldn't
go on our todo list.
I think you're asking for more scriptability in psql. Personally I
think that would be a great idea, but we need a lot
Thanks, applied.
---
Gregory Stark wrote:
We're currently printing the warning about connecting to the wrong version of
the server *before* syncing variables. On reconnecting this results in using
the *old* server
Bryce Nesbitt wrote:
Brendan Jurd wrote:
I really like the idea of wrapping, but after playing with the format
a bit myself, I have to agree with Tom that breaking in the middle of
words produces some very nasty output.
If the format could be improved to only wrap on word boudaries,
Bruce Momjian wrote:
Also, about the format 'auto' idea that uses expanded display, I am
thinking because expanded is a separate setting and not a format, I
should just add a possible 'auto' value to the expanded format that
could be triggered by either 'aligned' or 'wrapped' formats when the
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
The problem is, of course, generating the CREATE OR REPLACE statement.
There is some code to do this in pg_dump.c:dumpFunc(), but it's strongly
tied to pg_dump (global variables, output to Archive *, dependencies on
other functions, etc.).
I could
At 2008-06-15 23:35:34 -0400, [EMAIL PROTECTED] wrote:
There's been a lot of talk (but no action) about refactoring pg_dump
into a library plus wrapper.
Yes. After having tried to do what would have amounted to just a small
part of that work, I can see why nobody has done it yet.
I'd much
Patch applied, matching attached output. More suggestions welcomed.
---
Bruce Momjian wrote:
Shane Ambler wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
I promised to review our psql \?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Now that psql '\pset format wrapped' is in CVS, we should consider when
we want to use 'wrapped' format by default.
After experimenting for a bit, I'd say "never". This output format is
extremely ugly. Maybe if
On Tue, May 13, 2008 at 4:12 PM, Bryce Nesbitt [EMAIL PROTECTED] wrote:
Tom Lane wrote:
After experimenting for a bit, I'd say never. This output format is
extremely ugly. Maybe if it had enough smarts not to break in the
middle of words ...
regards, tom lane
Yet, wrapped is the same
Brendan Jurd wrote:
I really like the idea of wrapping, but after playing with the format
a bit myself, I have to agree with Tom that breaking in the middle of
words produces some very nasty output.
If the format could be improved to only wrap on word boudaries, that
would increase its appeal
Bryce Nesbitt wrote:
It's not that hard to do.
I chose not to, when writing the patch, because it makes the result flow
over many more lines.
And regardless, it pretty much has to cut long words, of which there
are many in typical SQL output.
And, I hardly ever read actual large blocks
Bruce Momjian wrote:
I think we can wrap if there is whitespace within a few characters
before the break point, and use a dash if we have to break a word. Is
that what people want?
Ugh.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
Bruce Momjian wrote:
I promised to review our psql \? output to see if I could improve it,
particularly the General section at the top. Below are the results.
Are the new sections ideal, and in the best ordering? Should \copyright
be kept in General at the top? Should \? be listed?
Why
Alvaro Herrera wrote:
Bruce Momjian wrote:
I promised to review our psql \? output to see if I could improve it,
particularly the General section at the top. Below are the results.
Are the new sections ideal, and in the best ordering? Should \copyright
be kept in General at the top?
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I think we can wrap if there is whitespace within a few characters
before the break point, and use a dash if we have to break a word. Is
that what people want?
Ugh.
Inserting dashes would be a truly horrid idea: ab and a-b mean
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I think we can wrap if there is whitespace within a few characters
before the break point, and use a dash if we have to break a word. Is
that what people want?
Ugh.
Inserting dashes would be a truly
1001 - 1100 of 1586 matches
Mail list logo
