> "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
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 in
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
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 w
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 SQL
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
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() sup
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 's toupper()/tolower().
It's been suggested that we could use where ava
> "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
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]
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
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
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 levels
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 havi
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 Object-Orien
"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 $col
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 d
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 libr
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
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
20 matches
Mail list logo
