According to the release notes of 8.2, the following item should have been implemented, E.1.3.11.
psql ChangesSave multi-line statements as a single entry, rather than
one line at a time (Sergey E. Koposov)
This makes up-arrow recall of queries easier.
The
On Fri, Oct 06, 2006 at 10:28:21PM -0400, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > The existing patch's behavior is that "the rightmost switch wins",
> > ie, if an object's name matches more than one pattern then it is
> > included or excluded according to the rightmost sw
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't inv
I wrote:
> One argument that occurs to me for importing the psql code is that it's
> solved the problem of including a schema name in the pattern. It would
> be a lot nicer to say "-t schema.table" than to have to say "-t table -n
> schema".
The more I think about this, the more I think the above
Tom,
> I kinda like that, because it makes the behavior completely independent
> of switch ordering, which seems like a good property to preserve.
> Anyone else have an opinion pro or con?
The only "con" argument I can think of is that "tar" and "rsync", whose syntax
is familiar to a lot of sysa
I've built man pages for 8.2beta1. They are on the FTP server at the
usual place and should appear in the next tarball.
Please let me know if you find formatting mistakes.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The existing patch's behavior is that "the rightmost switch wins", ie, if an
>> object's name matches more than one pattern then it is included or excluded
>> according to the rightmost switch it matches.
> My firs
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Chris Campbell wrote:
>> If that's the case, how hard would it be to link only psql with
>> readline (or libedit)?
> This is already addressed, more or less, in 8.2.
We've suppressed libreadline in the backend, but not in any of the other
client prog
I wrote:
> I have just realized that getrlimit(RLIMIT_STACK) is a pretty widely
> available syscall --- it's specified by the Single Unix Spec and the
> man pages claim it works on all the platforms I have handy to check.
> I propose that we make use of this call where available to prevent
> people
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> And the java program crashing the backend is attached. (it is generally
> one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't invoke
from psql :-(. Fixed, but we re
Josh Berkus wrote:
> I'd really like to get the Japanese translations merged with the main
> distribution. I've asked JPUG about this, and haven't been able to
> get an answer on whether this is reasonable for 8.2. Do you have
> any idea?
I don't know what format they have or why they have neve
Chris Campbell wrote:
> If that's the case, how hard would it be to link only psql with
> readline (or libedit)?
This is already addressed, more or less, in 8.2.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> As I did before, I send the strace ouput showing what jdbc is sending to the
> backend.
Thanks. I've been able to reproduce it now, and I think the plan is
actually OK, but for some reason the wrong rtable list is getting sent
along to the execut
Tom Lane <[EMAIL PROTECTED]> writes:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
>> I've found a bug with 8.2beta1:
>
> Can you put together a self-contained test case for this? The planner
> is evidently generating an incorrect plan from that messy view, but
> trying to reverse-engineer th
Tom,
OK, figured out what happened. I submitted the desired change,
*coincidentally* right before the error message got broken. As a result, I
mistakenly believed that the behaviour had been fixed by someone else before
I could get to a patch. Since I was travelling at the time (OSCON) I d
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql) (it's
possible to rewrite it in C with libpq, but I cannot do that very easily).
As I did before, I send t
I've grepped through the source code, and the only thing I can find
that uses readline (or libedit) is psql.
Is that correct?
If that's the case, how hard would it be to link only psql with
readline (or libedit)?
Currently, if you ./configure with readline support, -lreadine (or -
ledit)
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
So, the database schema with little data and a few functions is here
http://lnfm1.sai.msu.ru/~math/public
I have just realized that getrlimit(RLIMIT_STACK) is a pretty widely
available syscall --- it's specified by the Single Unix Spec and the
man pages claim it works on all the platforms I have handy to check.
I propose that we make use of this call where available to prevent
people from setting max_s
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
My guess is that there's some rewriter interaction involved, which means
that the rule itself is part of the problem --- you'll likely not be
abl
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
cas=# explain UPDATE table_list SET description = 'tag{image
SRC="/vizier/new2.gif"}3rd release of DENIS (2005Sep)' WHERE id =
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
I'll try, but it will be quite hard.
is evidently generating an incorrect plan from that messy view, b
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete scenario from what you've told
us loo
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It looks like it should work to have just one polymorphic aggregate
definition, eg, array_accum(anyelement) returns anyarray.
I was hoping to do that, but since it's an aggregate the ffunc format
Hello -hackers,
I've found a bug with 8.2beta1:
1) Log message:
LOG: duration: 9.144 ms bind : UPDATE table_list SET description
= $1 WHERE id = cas_get_table_id ( $2,$3 )
DETAIL: parameters: $1 = '\tag{image SRC="/vizier/new2.gif"}3rd release of
DENIS (2005Sep)', $2 = 'cas_data_sega', $3 =
25 matches
Mail list logo
