On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
Hi,
Is there any way of making the 'up' arrow retrieve all of the last
multiline query, instead of just the last line? It's really annoying
working with large multiline queries at the moment...
Not that I know of, but you
Hi guys,
Just compiled PG 7.3.1 on Solaris 8 x86, and it failed the GEOMETRY
regression test with one of those 15th decimal place is one digit
different from expected types of errors.
Nothing critical, but not sure if we're trying to have the correct
results already accounted for, for Solaris
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
FETCH LAST should return the last one row.
That's not clear to me. Generally, I would think the cursor should
remain positioned on whatever row is returned, but the spec clearly says
that the final cursor
FETCH LAST should return the last one row.
FETCH RELATIVE m should return a row after skipping
m rows if we follow the SQL standard and so the current
implementation of FETCH RELATIVE is broken.
Yes, the syntax could probably be
FETCH [n] RELATIVE m
to keep the
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
Hi,
Is there any way of making the 'up' arrow retrieve all of the last
multiline query, instead of just the last line? It's really annoying
working with large
On Wednesday 08 January 2003 13:02, Alexander M. Pravking wrote:
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
Hi,
Is there any way of making the 'up' arrow retrieve all of the last
multiline query,
On Wed, 8 Jan 2003, Christopher Kings-Lynne wrote:
Hi,
Is there any way of making the 'up' arrow retrieve all of the last multiline
query, instead of just the last line? It's really annoying working with
large multiline queries at the moment...
When you say multiline do you mean this:
On Tue, 2003-01-07 at 22:58, Tom Lane wrote:
It also logged that it was killed with signal 9, although I didn't kill it!
Is there something weird going on here?
Is this Linux? The Linux kernel seems to think that killing
randomly-chosen processes with SIGKILL is an appropriate response
On Saturday 04 January 2003 19:58, Marc G. Fournier wrote:
Let me know how it goes, and what the project is ... that way we can move
the current CVS over so that we don't lose the extensive logging history
Hmm. I didn't think that it was suggested to move the repository again. I
thought I
On Tue, 2003-01-07 at 21:59, Peter Eisentraut wrote:
- Some letters, like the euro sign, do not belong to Latin1. Example: let's
say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I
input a euro sign, does it get rejected by PostgreSQL?
Currently, it gives you a
Is there any way of making the 'up' arrow retrieve all of the last multiline
query, instead of just the last line? It's really annoying working with
large multiline queries at the moment...
When you say multiline do you mean this:
template1=$ select * from
template1-$ abc a
No analyze for 7.1.3.
Just ran vacuum a few minutes before the query. No boost at all. Even
with SET enable_seqscan = 0 it still does a table scan.
Dann, I can attest to 7.2 having a much better planner and performance
than 7.1 did. Can you upgrade?
---(end of
Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
What we really need is something better than sync(), viz flush all dirty
buffers to disk *and* wait till they're written. But sync() and sleep
for awhile is the closest portable approximation.
Are you saying that fsync() might not
Justin Clift [EMAIL PROTECTED] writes:
Just compiled PG 7.3.1 on Solaris 8 x86, and it failed the GEOMETRY
regression test with one of those 15th decimal place is one digit
different from expected types of errors.
I don't think we really care anymore about that; CVS tip has a modified
D'Arcy J.M. Cain wrote:
On Saturday 04 January 2003 19:58, Marc G. Fournier wrote:
Let me know how it goes, and what the project is ... that way we can move
the current CVS over so that we don't lose the extensive logging history
Hmm. I didn't think that it was suggested to move the
Tom Lane writes:
case T_VacuumStmt:
/* No XactReadOnly check since this logically changes no data */
vacuum((VacuumStmt *) parsetree);
break;
Then it'll be hard to miss the need to think about this when adding a
new statement.
Well, I had one
-Original Message-
From: scott.marlowe [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 6:30 AM
To: Dann Corbit
Cc: johnn; [EMAIL PROTECTED]
Subject: Re: [GENERAL] [HACKERS] I feel the need for speed.
What am I doing wrong?
No analyze for 7.1.3.
Just ran
Alexander M. Pravking [EMAIL PROTECTED] writes:
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
Is there any way of making the 'up' arrow retrieve all of the last
multiline query, instead of just the last line?
Tom Lane wrote:
Alexander M. Pravking [EMAIL PROTECTED] writes:
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
Is there any way of making the 'up' arrow retrieve all of the last
multiline query, instead of
On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
Tom Lane wrote:
Alexander M. Pravking [EMAIL PROTECTED] writes:
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne
wrote:
Is there any way of making the 'up' arrow
On Tuesday 07 January 2003 18:36, Steve Crawford wrote:
I'm busy trying to set up AOLserver to access PostgreSQL. Can you offer any
advice on what driver to use (docs aren't entirely clear on the virtues of
the internal PostgreSQL driver vs. the ARSdigita driver and it looks like
the ARSdigita
Jean-Michel POURE writes:
Finally, when you display East Asian characters you will
have a font problem because the Chinese, Japanese, and Korean characters
are mapped to the same range in Unicode but you are supposed to use
country-specific glyphs.
Do you mean that glyph hexaX will
- Some letters, like the euro sign, do not belong to Latin1. Example: let's
say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I
input a euro sign, does it get rejected by PostgreSQL?
Currently, it gives you a warning and ignores the character. Not sure
Hiroshi Inoue [EMAIL PROTECTED] writes:
I'm suspicios if we should implement scrollable cursors
with the combination of the current MOVE and FETCH implemen-
tation. For example the backwards FETCH operation for group
nodes isn't implemented properly yet(maybe).
Yeah, backwards scan is not
OK, patch applied to HEAD and 7.3.X. It does suppress options that are
already the default: (patch attached)
That is:
test= CREATE TABLE a1 (x int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'a1_pkey'
for table 'a1'
I said:
Yeah, backwards scan is not implemented for quite a large number of plan
node types :-(. I am not sure that it is practical to fix them all.
I have been toying with the notion of making cursors on complex plans
safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if
the
Tom Lane wrote:
Perhaps we could do something with a hybrid technique: don't materialize
the cursor output unless user actually asks for backwards scan.
Or we can check the existence of SCROLL keyword which is
currently ignored. In the first place SQL standard only
Tom Lane kirjutas N, 09.01.2003 kell 04:05:
I said:
Yeah, backwards scan is not implemented for quite a large number of plan
node types :-(. I am not sure that it is practical to fix them all.
I have been toying with the notion of making cursors on complex plans
safe for FETCH BACKWARD
Zeugswetter Andreas SB SD wrote:
FETCH LAST should return the last one row.
FETCH RELATIVE m should return a row after skipping
m rows if we follow the SQL standard and so the current
implementation of FETCH RELATIVE is broken.
Yes, the syntax could probably be
Files removed.
---
Sailesh Krishnamurthy wrote:
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
Why is it that bit.h is in src/include/utils and bit.c is in
Actually, CVS HEAD now builds and compiles quite cleanly on the Alpha. I'm
not sure what you did to fix it? Perhaps it's not compiling in ipv6 at all?
If so, probably doesn't matter.
Anyway, it's all fine now.
Chris
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Christopher Kings-Lynne wrote:
Actually, CVS HEAD now builds and compiles quite cleanly on the Alpha. I'm
not sure what you did to fix it? Perhaps it's not compiling in ipv6 at all?
If so, probably doesn't matter.
Yes, I think it is accurate that it isn't compiling at all. I modified
the
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I'm suspicios if we should implement scrollable cursors
with the combination of the current MOVE and FETCH implemen-
tation. For example the backwards FETCH operation for group
nodes isn't implemented properly
33 matches
Mail list logo
