Thread: Re: MySQL and BerkleyDB (fwd)
Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
something that everyone else has except us?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
---------- Forwarded message ----------
Date: Mon, 22 Jan 2001 09:03:58 -0600
From: Dave Glowacki <dglo@sweetpea.ssec.wisc.edu>
To: The Hermit Hacker <scrappy@hub.org>
Cc: Radovan Gibala <gigi@agraf.sk>, ports@freebsd.org
Subject: Re: MySQL and BerkleyDB
The Hermit Hacker wrote:
> On Mon, 22 Jan 2001, Radovan Gibala wrote:
> > Is there any possibility to get a port for MySQL with BerkleyDB support?
> > I realy need the transaction support and I'd like to build MySQL from a
> > port.
>
> why not just build PgSQL, and have transaction support *with* subselects
> and everything else that mySQL doesn't have?
I'd *love* to use PgSQL, but it doesn't support cross-DB joins (or at
least I couldn't figure out how to do it.) MySQL handles this, so
I'm using MySQL and would also like to have transaction support...
On Mon, Jan 22, 2001 at 11:30:17AM -0400, The Hermit Hacker wrote:
>
> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> something that everyone else has except us?
Afaik either Informix or Sybase (both?) has it too. Dunno about
anything else.
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
> ---------- Forwarded message ----------
> Date: Mon, 22 Jan 2001 09:03:58 -0600
> From: Dave Glowacki <dglo@sweetpea.ssec.wisc.edu>
> To: The Hermit Hacker <scrappy@hub.org>
> Cc: Radovan Gibala <gigi@agraf.sk>, ports@freebsd.org
> Subject: Re: MySQL and BerkleyDB
>
> The Hermit Hacker wrote:
> > On Mon, 22 Jan 2001, Radovan Gibala wrote:
> > > Is there any possibility to get a port for MySQL with BerkleyDB support?
> > > I realy need the transaction support and I'd like to build MySQL from a
> > > port.
> >
> > why not just build PgSQL, and have transaction support *with* subselects
> > and everything else that mySQL doesn't have?
>
> I'd *love* to use PgSQL, but it doesn't support cross-DB joins (or at
> least I couldn't figure out how to do it.) MySQL handles this, so
> I'm using MySQL and would also like to have transaction support...
>
>
--
marko
The Hermit Hacker writes:
> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> something that everyone else has except us?
It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
schema support, which will accomplish the same thing. Many people
(including myself) are of the opinion that not allowing cross-db access is
in fact a feature.
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
> ---------- Forwarded message ----------
> Date: Mon, 22 Jan 2001 09:03:58 -0600
> From: Dave Glowacki <dglo@sweetpea.ssec.wisc.edu>
> To: The Hermit Hacker <scrappy@hub.org>
> Cc: Radovan Gibala <gigi@agraf.sk>, ports@freebsd.org
> Subject: Re: MySQL and BerkleyDB
>
> The Hermit Hacker wrote:
> > On Mon, 22 Jan 2001, Radovan Gibala wrote:
> > > Is there any possibility to get a port for MySQL with BerkleyDB support?
> > > I realy need the transaction support and I'd like to build MySQL from a
> > > port.
> >
> > why not just build PgSQL, and have transaction support *with* subselects
> > and everything else that mySQL doesn't have?
>
> I'd *love* to use PgSQL, but it doesn't support cross-DB joins (or at
> least I couldn't figure out how to do it.) MySQL handles this, so
> I'm using MySQL and would also like to have transaction support...
>
>
>
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> On Mon, Jan 22, 2001 at 11:30:17AM -0400, The Hermit Hacker wrote:
>> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
>> something that everyone else has except us?
Think "schema". I don't foresee supporting joins across multiple
databases any time soon (unless someone wants to resurrect the old
Mariposa code), but once we have schemas you can put things into
different schemas of one database and get most of the user-level
benefit of multiple databases, while still being able to join to
things that are in other schemas.
I haven't looked hard at what it will take to do schemas, but it's
high on my priority list for 7.2. Ross Reedstrom has already done
some preliminary work ...
regards, tom lane
> It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
> schema support, which will accomplish the same thing. Many people
> (including myself) are of the opinion that not allowing cross-db access is
> in fact a feature.
I am hoping that when we get to query tree redesign we will have the
hooks to do distributed databases etc. Then "cross-db access" will come
nearly for free, which the user can choose to use or not.
- Thomas
Peter Eisentraut wrote:
>
> The Hermit Hacker writes:
>
> > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > something that everyone else has except us?
> It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
> schema support, which will accomplish the same thing. Many people
> (including myself) are of the opinion that not allowing cross-db access is
> in fact a feature.
I am of the inverse opinion : cross-DB joining is the only reasonable
way to cope with the unfortunate, disgracious, unreasonable, but quite
inescapable real-life fact that all data do not live in the same server
in any but the smallest sites ...
I recently did a plea in this list ("A post-7.1 wishlist") in this
direction, and got an answer (Peter Einstraut ?) that was more or less
on the lines of "over our dead bodies !" ... Sigh ...
However, I *think* that it could be done by another tool, such as
Easysoft's (Nick Gorham's, I think) SQL Engine, which allows for joins
between any ODBC-reachable tools. This tool is unreasonably expensive
for private use ($800 + $200/year mandatory maintainance). A PostgreSQL
alternative would be, IMSAO, a huge benefit, even huger if able to
cross-join with ODBC data sources ...
M$ Access has this, since version 1, and that's a hell of a handy
feature for a lot of cases involving management of multiple data sources
...
> > > why not just build PgSQL, and have transaction support *with* subselects
> > > and everything else that mySQL doesn't have?
> >
> > I'd *love* to use PgSQL, but it doesn't support cross-DB joins (or at
> > least I couldn't figure out how to do it.) MySQL handles this, so
> > I'm using MySQL and would also like to have transaction support...
I have to tell that my daily work involves this kind of problems, with
data sources ranging from SAS datasets under MVS/XA to Excel files to
Oracle databases to younameit ... That's the kind of problem I would
*love* to have PostgreSQL to cope with, and *not* M$ Access ...
[ Back to lurking mode ... ]
E. Charpentier
--
Emmanuel Charpentier
Emmanuel Charpentier wrote: > > Peter Eisentraut wrote: > Re: cross-database joins > > However, I *think* that it could be done by another tool, such as > Easysoft's (Nick Gorham's, I think) SQL Engine, which allows for joins > between any ODBC-reachable tools. This tool is unreasonably expensive > for private use ($800 + $200/year mandatory maintainance). A PostgreSQL > alternative would be, IMSAO, a huge benefit, even huger if able to > cross-join with ODBC data sources ... > > M$ Access has this, since version 1, and that's a hell of a handy > feature for a lot of cases involving management of multiple data sources You should probably use some front-end tools for most of it (I'd recommend Zope - http://www.zope.org/ ) Or you could try to make something up starting from Gadfly (an all-python SQL databse engine) that is included with zope and also available separately. ... > I have to tell that my daily work involves this kind of problems, with > data sources ranging from SAS datasets under MVS/XA to Excel files to > Oracle databases to younameit ... That's the kind of problem I would > *love* to have PostgreSQL to cope with, and *not* M$ Access ... OTOH, much of it could be done if postgres functions could return datasets, which is planned for not too distant future. -------------------- Hannu