Thomas Zehetbauer [EMAIL PROTECTED] writes:
Also will the BUG which causes postgresql to execute a sequential scan
when using min()/max()/count() ever be fixed? min()/max() can be
rewritten as SELECT $column ORDER BY $column ASC/DESC LIMIT 1 but this
should be done by the database, NOT by
Does anyone know this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204000
We should try to find out if this still errors before releasing 7.4,
don't you think?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL
Michael Meskes [EMAIL PROTECTED] writes:
Does anyone know this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204000
The bug reporter is in error to be claiming he is running 7.3.3, because
the assert() in question is at line 334 not 331 in 7.3.3. He may have
7.3.3 client
Greg Stark wrote:
Thomas Zehetbauer [EMAIL PROTECTED] writes:
Also will the BUG which causes postgresql to execute a sequential scan
when using min()/max()/count() ever be fixed? min()/max() can be
rewritten as SELECT $column ORDER BY $column ASC/DESC LIMIT 1 but this
should be done by the
Joshua D. Drake [EMAIL PROTECTED] writes:
Greg Stark wrote:
Thomas Zehetbauer [EMAIL PROTECTED] writes:
Also will the BUG which causes postgresql to execute a sequential scan
when using min()/max()/count() ever be fixed? min()/max() can be
rewritten as SELECT $column ORDER BY $column
Anthony,
And don't other databases have both theory and model?
Actually, no, the new databases do not.
The relational model is backed by relational algebra and relational calculus,
plus a series of postulates and laws which have been refined and tested over
20 years.
Not
Greg Stark wrote:
The more I think about this vacuum i/o problem, the more I think we have it
wrong. The added i/o from vacuum really ought not be any worse than a single
full table scan. And there are probably the occasional query doing full table
scans already in those systems.
For the folks
I was somewhat idly looking at the TODO list, and saw a few things I
might be competent to work on. However, I have no idea at all what
things are most important to users. ISTM it might be helpful to have a
rough priority level for reach item that would give a clue (maybe 3 or 4
priority
On Sun, 2003-10-19 at 17:09, Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
Does anyone know this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204000
The bug reporter is in error to be claiming he is running 7.3.3, because
the assert() in question is at line 334
There is a bug in Unicode upper() which has been present since 7.2:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139389
I had thought I had reported it before, but I can't find a record of it.
The attached Perl script illustrates the bug (the script needs DBI).
--
Oliver Elphick
Not sure how this got missed, but we definitely need to increment the
version number on libpq.so for 7.4.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Josh == Josh Berkus [EMAIL PROTECTED] writes:
This is an unfair characterization of XML databases, and I can say
this without accusations of bias for I vastly prefer working with the
relational model.
Josh Actually, amusingly enough, there is a body of theory
Josh backing XML
Oliver Elphick [EMAIL PROTECTED] writes:
There is a bug in Unicode upper() which has been present since 7.2:
We don't support upper/lower in multibyte character sets, and can't as
long as the functionality is dependent on ctype.h's toupper()/tolower().
It's been suggested that we could use
Some comments on random TODO entries:
* Allow INET subnet tests using non-constants
This should say Allow ... to be indexed as it's otherwise a nonissue.
* ARRAYS
o -Allow arrays to be ORDER'ed
Although Joe implemented ordering operators, he didn't get around to
adding MIN()/MAX()
o Add SET SCHEMA
What is this supposed to do (and how's it different from SET SEARCH_PATH)?
I believe someone thought it was the SQL standard way of doing it.
Probably needs to be checked though.
Chris
---(end of broadcast)---
TIP 6: Have you
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
o Add SET SCHEMA
What is this supposed to do (and how's it different from SET SEARCH_PATH)?
I believe someone thought it was the SQL standard way of doing it.
Probably needs to be checked though.
I can find no mention of it in SQL99.
In an attempt to throw the authorities off his trail,
[EMAIL PROTECTED] (Sailesh Krishnamurthy) transmitted:
Josh == Josh Berkus [EMAIL PROTECTED] writes:
This is an unfair characterization of XML databases, and I can say
this without accusations of bias for I vastly prefer working with
the
Gaetano Mendola wrote:
The vacuum cost is the same of a full scan table ( select count(*) ) ?
Why not do a sort of vacuum if a scan table happen ( during a simple
select that invole a full scan table for example )?
I was thinking about it. How about vacuuming a page when it is been pushed out
of
Sailesh,
Warning: I get carried away in this response. I'm afraid that I'm a fond
reader of Fabian Pascal and CJ Date, so I have far too much to say on the
topic. So if you really care about XML databases, you should probably hold
off on reading the rest until you're well-caffinated and
Christopher == Christopher Browne [EMAIL PROTECTED] writes:
Christopher Ah, but do papers honestly indicate the emergence
Christopher of some underlying theoretical model for which
Christopher fidelity could be evaluated?
Certainly. The model is that of semi-structured data, where
20 matches
Mail list logo
