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 p
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
t
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]]
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
OK, Christopher, how should we deal with this? I don't think defining
_KERNEL is a good idea. The only thing I can think of, if only s6_addr
is standard, is to change:
dst->in.sin_addr.s_addr = src->in6.sin6_addr.s6_addr32[3];
into taking the last 4 array elements of s6_addr and doing
> > > - 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. No
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 prob
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 BA
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
all
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
>
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'
CREA
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 no
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
> -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.
> > Ju
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 ARSdig
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 mak
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 que
"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 la
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
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
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 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 fsyn
> 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
> > 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
>
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
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 w
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 resp
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 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
> > > multi
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
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 Solari
> 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 fun
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 yo
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 cur
34 matches
Mail list logo
