Bruce Momjian wrote:
The idea would be for the dash to appear outside where normal data
appears:
internal | RI_FKey_cas-| referential
; cade_del; integrity
If we don't allow a dash, I think wrapping on word boundaries will be
impossible because we can't
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the behaviour would be better if we were able to only break on
words, and make columns wider on those where words wouldn't fit.
select repeat('xyzzy', 10);
Now admittedly our current handling of this isn't all that great either,
but you
Bruce Momjian wrote:
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
Alvaro Herrera wrote:
Bruce Momjian wrote:
The idea would be for the dash to appear outside where normal data
appears:
internal | RI_FKey_cas-| referential
; cade_del; integrity
If we don't allow a dash, I think wrapping on word boundaries will be
Shane Ambler wrote:
Bruce Momjian wrote:
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
There's another serious usability problem here, which is that the pager
ability is not being used correctly. Consider the \df+ tg_* query I
used as example for another bug report. psql says that it is 27 rows; I
have my window taller than that (47 lines right now), yet the output is
actually *a
Alvaro Herrera wrote:
There's another serious usability problem here, which is that the pager
ability is not being used correctly. Consider the \df+ tg_* query I
used as example for another bug report. psql says that it is 27 rows; I
have my window taller than that (47 lines right now), yet
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Now that psql '\pset format wrapped' is in CVS, we should consider when
we want to use 'wrapped' format by default. I think psql \df and \dT
certainly can benefit from wrapped mode. \df+ even displays, though
there is
Brendan Jurd escribió:
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Now that psql '\pset format wrapped' is in CVS, we should consider when
we want to use 'wrapped' format by default. I think psql \df and \dT
certainly can benefit from wrapped mode. \df+ even
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
I for one would definitely like backslash commands with very wide
output to be wrapped by default.
(At least) one place where I would not like it is in \df+, because
wrapped function output would
* Brendan Jurd [EMAIL PROTECTED] [080509 14:43]:
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
I for one would definitely like backslash commands with very wide
output to be wrapped by default.
(At least) one place where I would not
Brendan Jurd wrote:
[ email paragraphs reordered.]
I seem to recall there was some discussion of an auto mode in the
original wrapping thread, but if there was any meaningful conclusion I
lost it in amongst the width detection flame war.
I wasn't going to bring up the 'auto' idea yet because
Brendan Jurd [EMAIL PROTECTED] wrote:
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian [EMAIL PROTECTED]
wrote:
Now that psql '\pset format wrapped' is in CVS, we should consider
when
we want to use 'wrapped' format by default. I think psql \df and
\dT
certainly can benefit from wrapped mode.
Brendan Jurd wrote:
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribi?:
I for one would definitely like backslash commands with very wide
output to be wrapped by default.
(At least) one place where I would not like it is in \df+, because
Aidan Van Dyk wrote:
-- Start of PGP signed section.
* Brendan Jurd [EMAIL PROTECTED] [080509 14:43]:
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribi?:
I for one would definitely like backslash commands with very wide
output to be wrapped
Kevin Grittner wrote:
Brendan Jurd [EMAIL PROTECTED] wrote:
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian [EMAIL PROTECTED]
wrote:
Now that psql '\pset format wrapped' is in CVS, we should consider
when
we want to use 'wrapped' format by default. I think psql \df and
\dT
certainly
On Fri, May 9, 2008 at 3:53 PM, in message
[EMAIL PROTECTED], Bruce Momjian
[EMAIL PROTECTED] wrote:
test= \pset format wrapped
Output format is wrapped.
test= \pset columns 50
Target width for wrapped format is 50.
test= explain analyze select * from pg_type,
Kevin Grittner wrote:
On Fri, May 9, 2008 at 3:53 PM, in message
[EMAIL PROTECTED], Bruce Momjian
[EMAIL PROTECTED] wrote:
test= \pset format wrapped
Output format is wrapped.
test= \pset columns 50
Target width for wrapped format is 50.
test= explain analyze
Bruce Momjian escribió:
Of course, running it on a 50-column display in 'aligned' mode isn't
going to look good either.
This is what I get by pasting from a 50-column aligned psql (8.3):
QUERY PLAN
Alvaro Herrera [EMAIL PROTECTED] wrote:
Bruce Momjian escribió:
My conclusion is that we have to make very sure that wrapped is
not
the default for explain.
This will cause me similar pain in other areas.
I'm glad I thought of an example with which others could easily
identify.
-Kevin
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 it had enough smarts not to break in the
On Sat, Apr 5, 2008 at 12:36 AM, Tom Lane [EMAIL PROTECTED] wrote:
Actually, I suggested that to the patch author and he accepted it as a
good idea:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00245.php
so let's see what he comes up with...
New patch submitted:
David BOURIAUD wrote:
Hello,
I don't really know since when those commands are provided by psql, but I
found them recently and was quite annoyed by the output given by both of
them.
Not certain since when but I would think from a very early version.
Though I find that the \du command's
On Apr 3, 2008, at 9:35 AM, Tom Lane wrote:
Dawid Kuroczko [EMAIL PROTECTED] writes:
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
Seems a bit useless --- if you prefer \x format, wouldn't you
prefer it
all the time? Or
On Thu, Apr 3, 2008 at 6:44 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Bruce Momjian escribió:
It seems more helpful if there were \x option to use extended format
only when the output is too wide. TODO already has:
o Add auto-expanded mode so expanded output is used if
Dawid Kuroczko escribió:
Hmm, seems doable.
I think that the followup discussion leads to implementing just \G (and
\x auto).
I think there should be a format Enum, which would take values like NORMAL,
EXTENDED, and EXTENDED_ONCE -- but this would be a much more invasive patch.
Oh, and
Dawid Kuroczko wrote:
2. Do we want \G? I would say yes. ;) But it should get discussed.
pgsql-general perhaps?
No. We have had little demand for the auto, let alone a \G. Once we
have auto I don't see a use for \G.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
Gregory Stark [EMAIL PROTECTED] writes:
The patch is simple enough and if it was all it would take I would say let's
go ahead even if it's something only Josh would use. But it isn't anywhere
near everything you would expect to have this work cleanly. Really you would
want to be able to type
Hi!
I have sent a patch to pgsql-patches:
http://archives.postgresql.org/pgsql-patches/2008-04/msg00050.php
...which adds \G command to psql client.
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
For example:
postgres=#
Dawid Kuroczko [EMAIL PROTECTED] writes:
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
Seems a bit useless --- if you prefer \x format, wouldn't you prefer it
all the time? Or at least often enough that the toggling command
On Thu, Apr 3, 2008 at 4:35 PM, Tom Lane [EMAIL PROTECTED] wrote:
Dawid Kuroczko [EMAIL PROTECTED] writes:
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
Seems a bit useless --- if you prefer \x format, wouldn't you
Dawid Kuroczko wrote:
On Thu, Apr 3, 2008 at 4:35 PM, Tom Lane [EMAIL PROTECTED] wrote:
Dawid Kuroczko [EMAIL PROTECTED] writes:
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
Seems a bit useless --- if you prefer
Bruce Momjian escribió:
It seems more helpful if there were \x option to use extended format
only when the output is too wide. TODO already has:
o Add auto-expanded mode so expanded output is used if the row
length is wider than the screen width.
Consider
On Thu, Apr 03, 2008 at 12:07:54PM -0400, Bruce Momjian wrote:
Alternating between formats using \x is, at least for me, a bit
cumbersome: usually _after_ I wrote a query I realize it would
look more readable in expanded format, which is a bit too late.
So I run the query, ctrl+c, \x,
Alvaro Herrera wrote:
Bruce Momjian escribi?:
It seems more helpful if there were \x option to use extended format
only when the output is too wide. TODO already has:
o Add auto-expanded mode so expanded output is used if the row
length is wider than the screen
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Thu, Apr 03, 2008 at 12:07:54PM -0400, Bruce Momjian wrote:
Alternating between formats using \x is, at least for me, a bit
cumbersome: usually _after_ I wrote a query I realize it would
look more readable in expanded
On Thu, Apr 03, 2008 at 01:06:26PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian escribi?:
It seems more helpful if there were \x option to use extended format
only when the output is too wide. TODO already has:
o Add auto-expanded mode so expanded
On Thu, Apr 3, 2008 at 2:43 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 01:06:26PM -0400, Bruce Momjian wrote:
Some sort of \x auto? Sounds interesting ...
Yep.
Having \df+ go to \x automatically sounds like a really great idea :)
you can get pretty good
On Thu, Apr 03, 2008 at 03:43:50PM -0400, Merlin Moncure wrote:
On Thu, Apr 3, 2008 at 2:43 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 01:06:26PM -0400, Bruce Momjian wrote:
Some sort of \x auto? Sounds interesting ...
Yep.
Having \df+ go to \x
On Thu, Apr 3, 2008 at 4:08 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 03:43:50PM -0400, Merlin Moncure wrote:
On Thu, Apr 3, 2008 at 2:43 PM, David Fetter [EMAIL PROTECTED] wrote:
On Thu, Apr 03, 2008 at 01:06:26PM -0400, Bruce Momjian wrote:
Some sort of \x
Bruce Momjian escribió:
Martijn van Oosterhout wrote:
I was thinking that maybe \x should have a one-shot mode, i.e.
\x query
does it only for this one statement. It would solve the OPs problem.
But break for others who want all output \x.
I think Martijn is proposing using it as
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian escribió:
Martijn van Oosterhout wrote:
I was thinking that maybe \x should have a one-shot mode, i.e.
\x query
does it only for this one statement. It would solve the OPs problem.
But break for others who want all output \x.
I think
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think Martijn is proposing using it as some sort of prefix which would
take effect only on the current query.
A bigger problem is that it doesn't play nicely at all with multi-line
queries.
Hmm, why wouldn't it? I assume it
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
A bigger problem is that it doesn't play nicely at all with multi-line
queries.
Hmm, why wouldn't it? I assume it would only be recognized if the query
buffer is empty.
Huh? The proposed syntax was
\x query...
What do
Tom Lane escribió:
Huh? The proposed syntax was
\x query...
What do you do when you'd like the query to extend over multiple lines?
Backslash commands can't cross lines.
Save the fact that the current query is extended, until query end? I
haven't actually looked at what the
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
Huh? The proposed syntax was
\x query...
What do you do when you'd like the query to extend over multiple lines?
Backslash commands can't cross lines.
Save the fact that the current query is extended, until query end?
Yech.
* Alvaro Herrera [EMAIL PROTECTED] [080327 12:58]:
I was under the impression that I could start a psql -f pipe and then
feed it commands through the pipe using echo, and expect it to hang from
one command to the next. Of course, this doesn't work -- my guess is
that echo sends an EOF after
Aidan Van Dyk wrote:
I've had to use:
while (true); do cat pipe; done | psql
The trick is that pipes EOFs everytime the cleint closes it. (Not
strictly true, but it appears that way to basic read()ers).
Ah! Yeah, I knew that and forgot :-) It's easier than that actually --
you
* Alvaro Herrera [EMAIL PROTECTED] [080327 13:51]:
Ah! Yeah, I knew that and forgot :-) It's easier than that actually --
you just need to keep the pipe open in another process. So I can do
this: first open a terminal with
$ psql -f foo
And then, in another terminal,
$ cat foo
Alvaro Herrera [EMAIL PROTECTED] writes:
I was under the impression that I could start a psql -f pipe and then
feed it commands through the pipe using echo, and expect it to hang from
one command to the next. Of course, this doesn't work -- my guess is
that echo sends an EOF after the line I
Added to TODO:
o Have \l+ show database size, if permissions allow
Ideally it will not generate an error for invalid permissions
---
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I'd find
Added to TODO:
o Prevent escape string warnings when object names have
backslashes
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00227.php
---
Gregory Stark wrote:
If you hit tab
[ catching up on email... ]
Gregory Stark [EMAIL PROTECTED] writes:
If you hit tab on a table name containing a \ you get spammed with a
series of WARNINGS and HINTS about nonstandard use of \\ in a string
literal:
Yeah. This is actually a generic problem for *all* applications using
Option 5 would be to deprecate the ability to use a \ in an object name.
Jon
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 8:14 AM
To: pgsql-hackers list
Subject: [HACKERS] Psql command-line completion bug
If you hit tab on a
Guillaume Lelarge [EMAIL PROTECTED] writes:
I'm not sure psql handles \dFp the right way. The query allows
translators to translate some columns' values but forgets to escape the
strings. So, here is a patch that escapes these translated strings.
This seems mighty ugly, and it's not the way we
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I'm not sure psql handles \dFp the right way. The query allows
translators to translate some columns' values but forgets to escape the
strings. So, here is a patch that escapes these translated strings.
This seems mighty ugly,
Guillaume Lelarge [EMAIL PROTECTED] writes:
Tom Lane a écrit :
This seems mighty ugly, and it's not the way we handle any other \d
command. Why is it needed for \dFp (and only that)?
The problem here is that Start parse is translated with Début de
l'analyse (which is a bad translation but
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
Tom Lane a écrit :
This seems mighty ugly, and it's not the way we handle any other \d
command. Why is it needed for \dFp (and only that)?
The problem here is that Start parse is translated with Début de
l'analyse (which is a
Guillaume Lelarge [EMAIL PROTECTED] writes:
Tom Lane a écrit :
We should be fixing it so that the translated strings never go to the
server and back at all. This doesn't seem amazingly hard for column
headings --- it'd take some API additions in print.c, I think.
I'll take a look at this.
I wrote:
describe.c's whole approach to this has always been pretty thoroughly
broken in my mind, because it makes untenable assumptions about the
client-side gettext() producing strings that are in the current
client_encoding. If they are not, the server will probably reject
the SQL query
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
This seems too far removed from the scene of the crime
Yeah, my zeroth attempt was to place this in gets_fromFile(), but there
you don't have
Peter Eisentraut [EMAIL PROTECTED] writes:
This should do better:
Looks good to me, though I'd suggest updating gets_fromFile's header comment:
- * The result is a malloc'd string.
+ * The result is a malloc'd string, or NULL on EOF or input error.
regards, tom lane
Martijn van Oosterhout napsal(a):
On Wed, Nov 14, 2007 at 09:33:17PM +0100, Zdenek Kotala wrote:
Sure, why not. To be honest I think that psql shouldn't be ignoring the
EISDIR error the kernel is returning.
But it works when you open directory in read-only mode. See posix
definition:
Am Mittwoch, 14. November 2007 schrieb Martijn van Oosterhout:
It's not the fopen that fails, it's the fgets that returns NULL. We
don't subsequently check if that's due to an I/O error or EISDIR or if
it's an end-of-file.
Here is a patch for this.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 14. November 2007 schrieb Martijn van Oosterhout:
It's not the fopen that fails, it's the fgets that returns NULL. We
don't subsequently check if that's due to an I/O error or EISDIR or if
it's an end-of-file.
Here is a patch for this.
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
This seems too far removed from the scene of the crime
Yeah, my zeroth attempt was to place this in gets_fromFile(), but there you
don't have any opportunity to report failure to the main loop. We'd need to
change the function signature to be
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
This seems too far removed from the scene of the crime
Yeah, my zeroth attempt was to place this in gets_fromFile(), but there you
don't have any opportunity to report failure to the main loop.
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
Should we do some kind of stat() before opening the file and abort if it's
a
directory?
Actually anything other than a plain file, right? (Do we really want to
be able to psql -f a_pipe?)
Sure, why not. To be honest I
Martijn van Oosterhout wrote:
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right? (Do we really want to
be able to psql -f a_pipe?)
Sure, why
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory doesn't complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right?
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory doesn't
complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right? (Do we really want
On Wed, Nov 14, 2007 at 09:33:17PM +0100, Zdenek Kotala wrote:
Sure, why not. To be honest I think that psql shouldn't be ignoring the
EISDIR error the kernel is returning.
But it works when you open directory in read-only mode. See posix
definition:
[EISDIR]
The named file is a
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory doesn't complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file,
Martijn van Oosterhout wrote:
To be honest I think that psql shouldn't be ignoring the
EISDIR error the kernel is returning.
We use fopen(), which doesn't appear to pass that on.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On Wed, Nov 14, 2007 at 10:25:23PM +0100, Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
To be honest I think that psql shouldn't be ignoring the
EISDIR error the kernel is returning.
We use fopen(), which doesn't appear to pass that on.
It's not the fopen that fails, it's the
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory
doesn't complain at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort
if it's a directory?
David Fetter wrote:
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory
doesn't complain at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and
On Thursday 01 November 2007 00:44:16 Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l should print this info at all.
andy wrote:
I know its way too late in the game, sorry, but it's a very small patch...
I was wondering if this could be added to 8.3: it adds the dbsize to \l
in psql.
8.3 is many months beyond feature-freeze, so no, that's not likely to
happen.
It looks like this:
List of
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l should print this info at all.
regards, tom lane
andy [EMAIL PROTECTED] writes:
I know its way too late in the game, sorry, but it's a very small patch...
(1) What's the performance impact? I should think that this makes \l orders
of magnitude slower.
(2) Doesn't this render \l entirely nonfunctional for users who don't
have CONNECT
Tom Lane wrote:
andy [EMAIL PROTECTED] writes:
I know its way too late in the game, sorry, but it's a very small patch...
(1) What's the performance impact? I should think that this makes \l orders
of magnitude slower.
(2) Doesn't this render \l entirely nonfunctional for users who don't
Subject: Re: [HACKERS] psql show dbsize?
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l should print this info at all
[EMAIL PROTECTED] (Tom Lane) writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l should print this info at all.
Its interesting
Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l should print this info at all.
Its
Tom Lane wrote:
andy [EMAIL PROTECTED] writes:
I know its way too late in the game, sorry, but it's a very small patch...
(1) What's the performance impact? I should think that this makes \l orders
of magnitude slower.
(2) Doesn't this render \l entirely nonfunctional for users
On 11/1/07, Chris Browne [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l
Brendan Jurd [EMAIL PROTECTED] writes:
I'd find this convenient too. Although \l+ would be more consistent
with the \d series of commands.
Putting it into \l+ would address my gripe about increased execution
time. The permissions angle still bothers me though. AFAIR there are
no psql
Tom Lane [EMAIL PROTECTED] writes:
Now, because we surround the pattern with ^...$ anyway, I can't offhand
see a use-case for putting $ with its regexp meaning into the pattern.
It's possible to still usefully use $ in the regexp, but it's existence at the
end means there should always be a
Gregory Stark [EMAIL PROTECTED] writes:
Incidentally, are these really regexps? I always thought they were globs.
They're regexps under the hood, but we treat . as a schema separator
and translate * to .*, which makes it look like mostly a glob scheme.
But you can make use of brackets, |, +,
On Mon, Jul 09, 2007 at 07:04:27PM +0100, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Now, because we surround the pattern with ^...$ anyway, I can't offhand
see a use-case for putting $ with its regexp meaning into the pattern.
It's possible to still usefully use $ in the
Jim C. Nasby [EMAIL PROTECTED] writes:
Unless you're doing muti-line regex, what's the point of a $ anywhere
but the end of the expression? Am I missing something? Likewise with ^.
Leaving out the backslashes, you can do things like (foo$|baz|qux)(baz|qux|)
to say that all 9 combinations of
On Apr 27, 2007, at 12:44 AM, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
I would like to suggest that we make psql default when in
interactive mode to
using AUTOCOMMIT=false and ON_ERROR_ROLLBACK=true.
That is *way* too big a behavioral change to make depend on
something as
Gregory Stark [EMAIL PROTECTED] writes:
I would like to suggest that we make psql default when in interactive mode to
using AUTOCOMMIT=false and ON_ERROR_ROLLBACK=true.
That is *way* too big a behavioral change to make depend on something as
fragile as whether psql thinks it's interactive or
Zoltan Boszormenyi wrote:
Hi,
this is with current CVS code:
# \dt
ERROR: did not find '}' at end of input node
Server log:
ERROR: did not find '}' at end of input node
It's working for me. Have you tried with a fresh checkout or after
running make clean before you build?
cheers
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Hi,
this is with current CVS code:
# \dt
ERROR: did not find '}' at end of input node
Server log:
ERROR: did not find '}' at end of input node
It's working for me. Have you tried with a fresh checkout or after
running make clean before you
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Actually to be fair, there was no agreement.
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Are you saying the URL is wrong or the
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Actually to be
1101 - 1200 of 1586 matches
Mail list logo
