Jeff Eckermann schrieb:
>
> Tom,
> Thanks very much for your full and clear answer.
> It's hard to imagine a general use for this facility, anyway.
> For me this is a one-off exercise, albeit a big one.
> Regards
>
There're commercial OO persistance frameworks out there, which create
there o
"Dominic J. Eidson" schrieb:
> > ...
> > What if I do a SELECT to check for a row. Then I do a INSERT. But between
> > SELECT and INSERT someone else inserted a row. NO I do not think that "good
> > programming" will solve this.
>
> Good design, together with good implementation, gets you a lo
David Wall schrieb:
>
> Now that MySQL has transaction support through Berkeley DB lib, and it's
> always had way more data types, what are the main advantages postgresql has
> over it? I don't think mysql has subselects and such, but they did add a
> master-slave replication feature as well a
not use it because it always gives me segamentation
faults - we were unable to use any library, which was build
using the cygnus development kit :-(
Some help out there ?
Marten Feldtmann
> Bruce Momjian wrote:
>
> > My big question is, what new challenges will we face as we become more
> > popular?
>
> The 3 greatest technical/engineering challenges:
1) system reliability
> & recoverability,
2) system reliability & recoverability, and
3) system reliability
> and reco
> Peter Eisentraut wrote:
>
>
> This is a really stu^H^H^H bad idea. I have hierarchies 5 levels deep
> with
> multiple inheritance, and I
> don't want to do a 10 way join just to retrieve an object.
>
> This is why RDBMS's performance sucks so incredibly badly on some
> applications.
> an ODBM
> 2) good books, like " C++ object databases" (David Jordan) has
> a lot material.
As an example:
Cattel, "The Object Database Standard ODMG 2.0"
Morgan Kaufmann, ISBN 1 - 55860 - 463 -4
Marten Feldtmann
ther clients
may use this number in the future.
If the application crashes you may loose some id's -- but this is
not practically a problem.
If something is not clear - please ask.
Marten Feldtmann
> [EMAIL PROTECTED] wrote:
> >
> > Hi Sheila,
> >
> > For general database design considerations (not specific to Postgres) I
> > disagree with the others on the use of serials and sequences. These
> > things never migrate well from platform to platform, they often break, and
> > dealing with t
> sounds intriguing. although it still use db, but because it
> does not need any special db feature (table-locking is
> common), it qualifys as "programmatical" solution.
>
> however, not totally understood yet, let's see:
>
> comparing to file locking (e.g. perl's flock)
> 1) locking is enf
> On Thu, 24 Feb 2000, root wrote:
>
> # > I'm writing this email to you from a notebook. Running Linux. And Postgres.
> # > :-) So, it's already being done (Notebooks aren't the issue here, I believe
> # > it's an issue of OS choices).
> #
> # There're still some Windows'95 and Windows'98 user
> On Mon, 21 Feb 2000 [EMAIL PROTECTED] wrote:
>
> Is there really an interest in spending the extra money for a
> Windows license to build a less reliable database server?
>
Hmmm, try to think about an application, which normally runs on a server,
but then is also wanted (with much less
> CREATE INDEX nx_info1 ON info (lastname);
> CREATE INDEX nx_info2 ON info (street_name);
>
> The select is as simple as this in most cases...
>
> SELECT * FROM info WHERE street_name LIKE 'MAIN%';
>
> .,,the table about 50MB worth, about 70,000 records. I have an index on
> 'lastname' and 'st
>
> AS for the process pool ... there are two camps here ... if you use
> threads, when one threads crashes the server, the server is done. With
> forking,if one backend dies, the server is still running ... in a 24x7
> shop, I'd rather the solution that doesn't die cause JoeBlow down the hall
>
> A while ago it was being held that the Postgres large object data type
> was too new and not sufficiently tested and mature to be used in a
> production environment. I am about to deploy a little database that
> involves storing large-ish text files (20-500k) which could be either done
> as larg
t's it ! All the other stuff mentioned here are syntactical
sugar for people doing object-oriented database queries over pgsql
or hoping to structure their work - but I do not see, that it's
a real win.
Very frustrating !
Marten Feldtmann
16 matches
Mail list logo