Are we losing momentum?
Bruce Momjian
are concerned about Red Hat dropping their Red Hat Database and instead
distributing PostgreSQL as part of Red Hat Enterprise Server, and they
are concerned about recent press articles about MySQL.
Let me address these. First, the Red Hat change probably has a lot to
do with Oracle's relationship with Red Hat, and very little to do with
PostgreSQL. Their pullback is similar to Great Bridge's closing, except
that Red Hat's database group is still around, so we aren't losing Tom
Lane or Patrick MacDonald (who is completing our PITR work for 7.4).
As far as MySQL, they have a company to push articles to the press, and
many writers just dress them up and print them --- you can tell them
because the pushed ones mention only MySQL, while the non=pushed ones
mention MySQL and PostgreSQL.
I have been around the globe enough to know that PostgreSQL is well on
track. Our user base is growing, we have Win32 and PITR ready for 7.4
(and each had some commercial funding to make them happen.) Recently, I
have also been fielding questions from several companies that want to
hire PostgreSQL developers to work for the community.
But most importantly, there is mind share. I get _very_ few questions
about MySQL anymore, and when the database topic comes up on Slashdot,
the MySQL guys usually end up looking foolish for using MySQL. And my
recent trip to Toronto (who's details I have shared with core but can
not discuss) left no doubt in my mind that PostgreSQL is moving forward
at a rapid rate.
And, I have 1.5k emails to read after a one week trip. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
Tom Lane
> Several people have asked if we are losing momentum.
I don't think we are losing momentum considering the project in
isolation --- things seem to be moving as well as they ever have,
if not better.
But I do sometimes worry that we are losing the mindshare war.
We might be growing fine, but if we're growing slower than MySQL is,
we've got a problem. I was just in the local Barnes & Noble store
yesterday, and could not help but notice how many books had "MySQL" in
the title. I didn't notice a single Postgres title (though I did not
look hard, since I was just passing through the computer area).
Mindshare eventually translates into results, if only because it
means that capable developers will gravitate there instead of here.
So we need to worry about it.
There isn't anyone presently willing to spend real money and effort on
marketing PG (as you say, Red Hat won't, for reasons that have nothing
to do with the merits of the product). That means that MySQL's
marketeers have a free hand to do things like boast about features that
might materialize in a year or so :-(
I don't know what we can do about it, other than maybe push harder to
get some more PG titles into O'Reilly's catalog ... that would help
narrow the bookshelf gap a little, at least. Any wannabee authors
out there? (And Bruce, your book is due for a second edition...)
regards, tom lane
Gavin Sherry
> Bruce Momjian <pg...@candle.pha.pa.us> writes:
> > Several people have asked if we are losing momentum.
>
> I don't think we are losing momentum considering the project in
> isolation --- things seem to be moving as well as they ever have,
> if not better.
I agree. I am surprised at the pace at which new features are added,
considering the relatively small number of people working on the project.
>
> But I do sometimes worry that we are losing the mindshare war.
> We might be growing fine, but if we're growing slower than MySQL is,
> we've got a problem. I was just in the local Barnes & Noble store
> yesterday, and could not help but notice how many books had "MySQL" in
> the title. I didn't notice a single Postgres title (though I did not
> look hard, since I was just passing through the computer area).
I've considered this at length. I put some ideas together in December and
sent it off to the advocacy list. Most/all were not implemented -- not
least because I didn't do anything I said I would :-). But, some of the
most important things, such as a proper media kit, quotes for journos,
press contacts with authority to give fast/correct answers really need to
be implemented.
As for why MySQL has *significantly* more market share: there's not a lot
we can match them on. They have significant financial backing -- important
if you're an IT manager who actually knows very little about the technical
merit of the product. It has close ties to a *very* widely deployed
scripting language (PHP). MySQL AB employs marketing and 'advocacy' staff,
who attend conferences all over the world, speak several languages, and
have a fairly good understanding of the industry, open source, databases,
etc. They have infrastructure: tech support, on site support,
consultancy.
MySQL AB promotes MySQL as a high performance database, easy to use,
uncomplicated, with features implemented in a way which is syntactically
convenient -- not 'complicated' like Oracle, DB2 or Postgres.
Its hard to argue against that. At a *technical* conference I recently
spoke at, I was criticised for delivering a talk which was too advanced
and didn't explain Postgres for MySQL users. During a lecture series at a
university, I was criticised for not discussing Oracle instead of Postgres
-- students told me that Oracle will make them money and Postgres wont.
Regardless, I'm still of the opinion that if you build it, they will come
-- particularly costly features like replication, PITR, etc. But maybe
that is what the BSDs say about Linux?
Gavin
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Kevin Brown
> During a lecture series at a university, I was criticised for not
> discussing Oracle instead of Postgres -- students told me that
> Oracle will make them money and Postgres wont.
Their impressions are probably based on reality as it was a couple of
years ago before the U.S. economy came crashing down.
But today? Companies are trying to figure out how to do things
cheaper, and there are a lot of situations for which Postgres is a
good fit but for which MySQL is a bad fit -- if it'll fit at all.
I seriously think the native Win32 port of Postgres will make a big
difference, because it'll be a SQL Server killer. Especially if it
comes with a nice administrative GUI. :-)
--
Kevin Brown ke...@sysexperts.com
Gavin Sherry
> Gavin Sherry wrote:
> > During a lecture series at a university, I was criticised for not
> > discussing Oracle instead of Postgres -- students told me that
> > Oracle will make them money and Postgres wont.
>
> Their impressions are probably based on reality as it was a couple of
> years ago before the U.S. economy came crashing down.
>
> But today? Companies are trying to figure out how to do things
> cheaper, and there are a lot of situations for which Postgres is a
> good fit but for which MySQL is a bad fit -- if it'll fit at all.
>
>
> I seriously think the native Win32 port of Postgres will make a big
> difference, because it'll be a SQL Server killer. Especially if it
> comes with a nice administrative GUI. :-)
I've been thinking about this too. Addressing Tom's point: any one with
Windows experience, interested in the native port and willing to write a
Windows book would probably do a lot for the project. For one, I would be
willing to help write parts which were not Windows specific -- as I
haven't used that system in some time :-).
Gavin
---------------------------(end of broadcast)---------------------------
Larry Rosenman
--On Monday, April 14, 2003 19:54:27 -0400 Tom Lane <t...@sss.pgh.pa.us>
wrote:
> Bruce Momjian <pg...@candle.pha.pa.us> writes:
>> Several people have asked if we are losing momentum.
>
> I don't think we are losing momentum considering the project in
> isolation --- things seem to be moving as well as they ever have,
> if not better.
>
> But I do sometimes worry that we are losing the mindshare war.
> We might be growing fine, but if we're growing slower than MySQL is,
> we've got a problem. I was just in the local Barnes & Noble store
> yesterday, and could not help but notice how many books had "MySQL" in
> the title. I didn't notice a single Postgres title (though I did not
> look hard, since I was just passing through the computer area).
I was in the Local MicroCenter, and found 3 PG titles, in addition to
Bruce's.
This is MUCH better than a year ago, when there were NONE.
Agreed, that MySQL, has a bigger shelf space.
I did all 3 authors a favor and bought copies.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: l...@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Brent Verner
[2003-04-14 19:54] Tom Lane said:
| Bruce Momjian <pg...@candle.pha.pa.us> writes:
| > Several people have asked if we are losing momentum.
| I don't know what we can do about it, other than maybe push harder to
| get some more PG titles into O'Reilly's catalog ... that would help
| narrow the bookshelf gap a little, at least. Any wannabee authors
| out there? (And Bruce, your book is due for a second edition...)
I've wanted to pipe up in a few of these "popularity"
discussions in the past. Seeing how I can't make time to
participate in any other meaningful capacity, I'll share
my thoughts on _why_ mysql has the mindshare.
Applications, specifically applications that _use_ mysql.
A quick search over at freshmeat returns 1044 results for
"mysql" and 260 for "postgresql". Before this turns into a
cause/effect discussion, I want to state up front that the
real "effect" of this is that someone is 4 times as likely to
download an application that uses mysql. Sure, many are
"trivial" applications, but I posit that it is _specifically_
these "trivial" applications that inoculate the uninitiated
with the belief that mysql is suitable for use in real, albeit
trivial applications. Additionally, it these rudimentary
applications that will be studied by many as the way to write
a database application.
It is all good and well that postgres /can/ do, but until
the application developers see that those features are
valuable enough to forgo mysql support, they'll write the
application to support whatever database is most likely to
_already_ be installed, which will be mysql. Granted,
many developers will also try to support multiple dbs via
the language's db api, but this leaves the less-supported
dbs in an even worse position; being relegated to an
"might work with XXX database". When anxious user learns
that "might" currently means "doesn't," the second-string
database looks even worse in the eyes of the user.
How to solve this problem? This is the hard part, but
luckily ISTM that there are a few ways to succeed. Neither
of which involves marketing or writing books.
1) become active in the "also supports postgres" projects,
and add features that are made available _because_ of
postgres' superiority. Eventually, market pressure
for the cool feature(s) will lead users to choose
postgres, and mysql could be relegated to the "also
runs on mysql, with limited featureset"
2) take a popular project that uses mysql, fork it, and
add features that can only be implemented using posgres.
3) release that super-cool code that you've been hacking
on for years, especially if it is a "trivial" app.
4) convince your employer that it would be _beneficial_ to
them to release, as open source, the internal app(s) you've
developed, using postgres-specific features. (This is
about all I can claim to be doing at this point in my
indentured servitude, and I can't say I'm doing a good
job... :-/)
I'm sure this idea is not original, but I'm also sure that
it _is_ the answer to gaining market^Wmindshare in this
database market.
(I must apologize in advance, that I might not have time
to even follow this thread, in fact, I hope that instead of
replying to this, the potential respondent might consider
helping to increase the number of apps that require postgres
:-)
wishing-I-could-contribute-more-ly yours,
brent
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Christopher Kings-Lynne
c3RncmVzIiBwcm9qZWN0cywNCj4gICAgICBhbmQgYWRkIGZlYXR1cmVzIHRo
YXQgYXJlIG1hZGUgYXZhaWxhYmxlIF9iZWNhdXNlXyBvZg0KPiAgICAgIHBv
c3RncmVzJyBzdXBlcmlvcml0eS4gIEV2ZW50dWFsbHksIG1hcmtldCBwcmVz
c3VyZQ0KPiAgICAgIGZvciB0aGUgY29vbCBmZWF0dXJlKHMpIHdpbGwgbGVh
ZCB1c2VycyB0byBjaG9vc2UNCj4gICAgICBwb3N0Z3JlcywgYW5kIG15c3Fs
IGNvdWxkIGJlIHJlbGVnYXRlZCB0byB0aGUgImFsc28NCj4gICAgICBydW5z
IG9uIG15c3FsLCB3aXRoIGxpbWl0ZWQgZmVhdHVyZXNldCINCg0KVGFrZSwg
Zm9yIGV4YW1wbGUsIHBocFBnQWRtaW4uICBJdCB3YXMgb3JpZ2luYWxseSBm
b3JrZWQgZnJvbSBwaHBNeUFkbWluLCBidXQgd2UndmUganVzdCBkb25lIGEg
Y29tcGxldGUgcmV3cml0ZSAoYmVjYXVzZSBwaHBNeUFkbWluIHdhcyB3cml0
dGVuIG15IG15c3FsL3BocCB3ZWVuaWVzIHdobyBjb3VsZG4ndCBjb2RlIG5p
Y2VseSB0byBzYXZlIHRoZWlyIGxpdmVzLi4uKS4NCg0KSG93ZXZlciwgaXQn
cyBtZSBkb2luZyA5OSUgb2YgdGhlIGNvZGluZywgUm9iIGRvaW5nIGFkdm9j
YWN5IGFuZCBhIGhlYXAgb2YgcGVvcGxlIHdobyBzZW5kIGluIHRyYW5zbGF0
aW9ucy4gIFRyYW5zbGF0aW9ucyBhcmUgdmVyeSBuaWNlLCBidXQgSSBzbyBy
YXJlbHkgZ2V0IGFjdHVhbCBjb2RlIGNvbnRyaWJ1dGlvbnMuDQoNCnBocE15
QWRtaW4gZXZlbiBpbXBsZW1lbnRzIGl0J3MgT1dOIGNvbW1lbnQgYW5kIGZv
cmVpZ24ga2V5IGZlYXR1cmUhIQ0KDQpDaHJpcw0KCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLShlbmQgb2YgYnJvYWRjYXN0KS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQpUSVAgMzogaWYgcG9zdGluZy9yZWFkaW5nIHRocm91
Z2ggVXNlbmV0LCBwbGVhc2Ugc2VuZCBhbiBhcHByb3ByaWF0ZQpzdWJzY3Jp
YmUtbm9tYWlsIGNvbW1hbmQgdG8gbWFqb3Jkb21vQHBvc3RncmVzcWwub3Jn
IHNvIHRoYXQgeW91cgptZXNzYWdlIGNhbiBnZXQgdGhyb3VnaCB0byB0aGUg
bWFpbGluZyBsaXN0IGNsZWFubHkK
cbbr...@cbbrowne.com
> I seriously think the native Win32 port of Postgres will make a big
> difference, because it'll be a SQL Server killer. Especially if it
> comes with a nice administrative GUI. :-)
I wouldn't be too sanguine about that, from two perspectives:
a) There's a moving target, here, in that Microsoft seems to be
looking for the next "new thing" to be the elimination of
the use of "files" in favor of the filesystem being treated
as a database.
b) We recently were considering how we'd put a sharable Windows box
in, at the office. Were considering using VNC to allow it to be
accessible. Then someone thought to read the license, only to
discover that the license pretty much expressly forbids running
"foreign, competing applications" on the platform.
It seems pretty plausible that the net result of further development
will be platforms that are actively hostile to foreign software.
If I suggested that the licensing of Win2003 would expressly forbid
installing PostgreSQL, people would rightly accuse me of being a
paranoid conspiracy theorist.
But considering that the thought of VNC being outlawed would have seemed
pretty daft a few years ago, and we see things like DMCA combining with
"Homeland Security." Anti-"hacking" provisions have been going into
telecom laws that appear to classify network hardware that can do NAT as
"illegal hacking" equipment. I'm not sure what we'd have to consider
"daft" come 2005...
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://cbbrowne.com/info/internet.html
"Heuristics (from the French heure, "hour") limit the amount of time
spent executing something. [When using heuristics] it shouldn't take
longer than an hour to do something."
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Curt Sampson
> Applications, specifically applications that _use_ mysql.
>
> A quick search over at freshmeat returns 1044 results for
> "mysql" and 260 for "postgresql".
That's a pretty reasonable thought. I work for a shop that sells
Postgres support, and even we install MySQL for the Q&D ticket tracking
system we recommend because we can't justify the cost to port it to
postgres. If the postgres support were there, we would surely be using it.
How to fix such a situation, I'm not sure. "MySQL Compatability Mode,"
anyone? :-)
cjs
--
Curt Sampson <c...@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Bruce Momjian
I agree, things aren't good when you look at the book shelf and app
support, but fortunately these are things that are shaded more by the
state of things 1-3 years ago rather than currently. Certainly, we
would have seen an even worse ratio than 1:4 if we had looked last year
--- we aren't on parity yet, but I think we are getting there.
---------------------------------------------------------------------------
Larry Rosenman wrote:
>
>
> --On Monday, April 14, 2003 19:54:27 -0400 Tom Lane <t...@sss.pgh.pa.us>
> wrote:
>
> > Bruce Momjian <pg...@candle.pha.pa.us> writes:
> >> Several people have asked if we are losing momentum.
> >
> > I don't think we are losing momentum considering the project in
> > isolation --- things seem to be moving as well as they ever have,
> > if not better.
> >
> > But I do sometimes worry that we are losing the mindshare war.
> > We might be growing fine, but if we're growing slower than MySQL is,
> > we've got a problem. I was just in the local Barnes & Noble store
> > yesterday, and could not help but notice how many books had "MySQL" in
> > the title. I didn't notice a single Postgres title (though I did not
> > look hard, since I was just passing through the computer area).
> I was in the Local MicroCenter, and found 3 PG titles, in addition to
> Bruce's.
>
> This is MUCH better than a year ago, when there were NONE.
>
> Agreed, that MySQL, has a bigger shelf space.
>
> I did all 3 authors a favor and bought copies.
>
> LER
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 972-414-9812 E-Mail: l...@lerctr.org
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
>
>
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Christopher Kings-Lynne
ayBmb3IgYSBzaG9wIHRoYXQgc2VsbHMNCj4gUG9zdGdyZXMgc3VwcG9ydCwg
YW5kIGV2ZW4gd2UgaW5zdGFsbCBNeVNRTCBmb3IgdGhlIFEmRCB0aWNrZXQg
dHJhY2tpbmcNCj4gc3lzdGVtIHdlIHJlY29tbWVuZCBiZWNhdXNlIHdlIGNh
bid0IGp1c3RpZnkgdGhlIGNvc3QgdG8gcG9ydCBpdCB0bw0KPiBwb3N0Z3Jl
cy4gSWYgdGhlIHBvc3RncmVzIHN1cHBvcnQgd2VyZSB0aGVyZSwgd2Ugd291
bGQgc3VyZWx5IGJlIHVzaW5nIGl0Lg0KPiANCj4gSG93IHRvIGZpeCBzdWNo
IGEgc2l0dWF0aW9uLCBJJ20gbm90IHN1cmUuICJNeVNRTCBDb21wYXRhYmls
aXR5IE1vZGUsIg0KPiBhbnlvbmU/IDotKQ0KDQpUaGUgcmVhbCBwcm9ibGVt
IGlzIFBIUC4gIFBIUCBpcyBqdXN0IHRoZSBjcnVmdGllc3QgbGFuZ3VhZ2Ug
ZXZlciBpbnZlbnRlZCAodHJ1c3QgbWUsIEkgdXNlIGl0IGV2ZXJ5IGRheSku
ICBUaGUgUEhQIHBlb3BsZSBhcmUgdG90YWxseSBkZWRpY2F0ZWQgdG8gTXlT
UUwsIHRvIHRoZSBleGNsdXNpb24gb2YgYWxsIHJhdGlvbmFsIHRob3VnaHQg
KGVnLiBXaGVuIEkgYXNrZWQgUmFzbWFzIGF0IGEgY29uZmVyZW5jZSBhYm91
dCByYWNlIGNvbmRpdGlvbnMgaW4gaGlzIHJlcGxpY2F0ZWQgc2V0dXAsIGhl
IHJlcGxpZWQgIml0J3MgbmV2ZXIgZ29pbmcgdG8gaGFwcGVuIC0gTXlTUUwn
cyByZXBsaWNhdGlvbiBpcyBqdXN0IHRvbyBmYXN0Li4uKS4NCg0KQ2hyaXMN
CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0oZW5kIG9mIGJyb2FkY2Fz
dCktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVElQIDY6IEhhdmUgeW91
IHNlYXJjaGVkIG91ciBsaXN0IGFyY2hpdmVzPwoKaHR0cDovL2FyY2hpdmVz
LnBvc3RncmVzcWwub3JnCg==
Mike Mascari
> Kevin, without the "e", wrote...
>
>>I seriously think the native Win32 port of Postgres will make a big
>>difference, because it'll be a SQL Server killer. Especially if it
>>comes with a nice administrative GUI. :-)
I agree. I don't think PostgreSQL will be a SQL Server killer,
but my completely ignorant guess is that 90% of the cause of the
*initial* gap between mySQL and PostgreSQL grew out of the fact
that a Win32 version of mySQL was available. Once the gap became
present, one then had to suffer switching costs. If the
features/performance of PostgreSQL > mySQL switching costs, then
PostgreSQL wins in the long term. Without a Win32 port, the
switching costs also include those switching costs associated
with switching from Win32 to Unix.
>
> I wouldn't be too sanguine about that, from two perspectives:
>
> a) There's a moving target, here, in that Microsoft seems to be
> looking for the next "new thing" to be the elimination of
> the use of "files" in favor of the filesystem being treated
> as a database.
They ought to get their database up to speed first, it seems to
me. I agree Microsoft's view of data management is a moving
target. 6 years ago everything, including network resources were
going to be accessed strickly through an OLE2 Compound Document
interface and OLE structured storage. Then the Internet got hot
and all data suddenly had to be accessible through URLs. Now
it's XML that hot. Perhaps the Microsoft filesystem of the
future will be one big XML document ;-)
>
> b) We recently were considering how we'd put a sharable Windows box
> in, at the office. Were considering using VNC to allow it to be
> accessible. Then someone thought to read the license, only to
> discover that the license pretty much expressly forbids running
> "foreign, competing applications" on the platform.
>
> It seems pretty plausible that the net result of further development
> will be platforms that are actively hostile to foreign software.
>
> If I suggested that the licensing of Win2003 would expressly forbid
> installing PostgreSQL, people would rightly accuse me of being a
> paranoid conspiracy theorist.
I think you are a paranoid conspiracy theorist. :-)
Mike Mascari
mas...@mascari.com
Christopher Browne
> I agree, things aren't good when you look at the book shelf and app
> support, but fortunately these are things that are shaded more by the
> state of things 1-3 years ago rather than currently. Certainly, we
> would have seen an even worse ratio than 1:4 if we had looked last year
> --- we aren't on parity yet, but I think we are getting there.
What's missing are the "FOO Applications With PostgreSQL" sorts of
books, where
(member FOO '(|Web| |PHP| |Perl| |Python| |Application Frameworks|))
The one PostgreSQL book that _does_ have some of this is the O'Reilly
one, where I was disappointed to see how much of the book was devoted to
a framework I /wasn't/ planning to use.
Right at the moment is probably /not/ a good time to be pushing books on
potentially-obscure application areas; my ex-publisher (Wrox) just
became an ex-publisher as a result of trying too hard to too quickly
hawk too many books in obscure application areas.
My suspicion is that this, along with very soft book sales throughout
the publishing industry, is likely to make "obscure application area"
books a tough sell in the short term. Like it or not, "PostgreSQL +
FOO" is not going to be the easiest sell, particularly in the absence of
the much denigrated "PostgreSQL Marketing Cabal."
--
output = ("cbbrowne" "@cbbrowne.com")
http://cbbrowne.com/info/wp.html
"There is no psychiatrist in the world like a puppy licking your
face." -- Ben Williams
Sailesh Krishnamurthy
Tom> But I do sometimes worry that we are losing the mindshare
Tom> war. We might be growing fine, but if we're growing slower
Tom> than MySQL is, we've got a problem. I was just in the local
This is probably true. Once people get exposed to PostgreSQL then
there is a fair chance of forming an opinion. Today one of the
undergraduates in my class was telling me how after hacking pgsql
internals he has such a different impression of the two systems
(earlier he'd built a site with MySQL going by the "works for
slashdot" philosophy).
--
Peace, at last ?
Sailesh
http://www.cs.berkeley.edu/~sailesh
Jeff Hoffmann
> cbbr...@cbbrowne.com wrote:
>>I wouldn't be too sanguine about that, from two perspectives:
>>
>> a) There's a moving target, here, in that Microsoft seems to be
>> looking for the next "new thing" to be the elimination of
>> the use of "files" in favor of the filesystem being treated
>> as a database.
>
>
> They ought to get their database up to speed first, it seems to
> me. I agree Microsoft's view of data management is a moving
> target.
Not to mention the fact that there's a significant number of NT 4
servers still out there -- what is that, 7 years old? A lot of places
aren't upgrading because they don't need to & don't want to shell out
the cash. (And it should go without saying that Microsoft is none too
happy with it.) With Windows 2K3 just coming out and who knows how much
longer until the next version (or ther version after that, who knows
when these "features" will actually show up), there's still a
significant window in there for conventional database servers,
especially for the price conscious out there.
----
Jeff Hoffmann
PropertyKey.com
Dann Corbit
> From: Jeff Hoffmann [mailto:je...@propertykey.com]=20
> Sent: Monday, April 14, 2003 8:54 PM
> To: pgsql-...@postgresql.org
> Subject: Re: [HACKERS] Are we losing momentum?
>=20
>=20
> Mike Mascari wrote:
> > cbbr...@cbbrowne.com wrote:
> >>I wouldn't be too sanguine about that, from two perspectives:
> >>
> >> a) There's a moving target, here, in that Microsoft seems to be
> >> looking for the next "new thing" to be the elimination of
> >> the use of "files" in favor of the filesystem being treated
> >> as a database.
This is a very, very good idea. In fact IBM has been doing it for
years. For that matter, so has OpenVMS. What's that -- 30 year old
technology?
I have always thought that a native file system should be a hierarchy
like Adabas(IBM Mainframe), DBMS(OpenVMS) or Raima(PC's & UNIX) for a
model. It is a very natural fit. The OS contains disk devices which
contain directories, subdirectories, and files. Set ownership model
seems to fit perfectly.
> > They ought to get their database up to speed first, it=20
> seems to me. I=20
> > agree Microsoft's view of data management is a moving target.
>=20
> Not to mention the fact that there's a significant number of NT 4=20
> servers still out there -- what is that, 7 years old? A lot=20
> of places=20
> aren't upgrading because they don't need to & don't want to shell out=20
> the cash. (And it should go without saying that Microsoft is=20
> none too=20
> happy with it.) With Windows 2K3 just coming out and who=20
> knows how much=20
> longer until the next version (or ther version after that, who knows=20
> when these "features" will actually show up), there's still a=20
> significant window in there for conventional database servers,=20
> especially for the price conscious out there.
SQL*Server is a very good database. The optimizer is outstanding for
complex queries.
There are clearly places where PostgreSQL does have a distinct
advantage. Price a 1000 user system for SQL*Server and PostgreSQL and
you will see that we can hire a couple of DBA's just for the price
difference. Since you can purchase PostgreSQL support, that is no
longer a significant advantage for MS.
And about MySQL:
It's also commercial. You are not supposed to use it except for a
single machine for personal use unless you are a non-profit organization
or unless absolutely everything you do is GPL[1]. Hence, you have to
license it to deploy applications. In order to have transactions, you
have to use another commercial product that they bolt into MySQL --
Sleepycat software's database. Now you have two license systems to
worry about.=20
Compared to PostgreSQL, both of these tools cost an arm and a leg.
SQL*Server is closed. You have to rely on MS to fix any problems that
crop up. MySQL has a very restrictive license [for those who might
happen to bother to read such things] for both modifications to the code
and also redistribution of applications.
[1] I realize that people cheat on this all the time. In theory, they
could all go to jail for it. It is certainly not a risk I would be
willing to take. I have also bumped into people who had no idea that
commercial use requires a commercial license for MySQL. There are
probably lots of people in that boat too.
Christopher Kings-Lynne
> It's also commercial. You are not supposed to use it except for a
> single machine for personal use unless you are a non-profit organization
> or unless absolutely everything you do is GPL[1]. Hence, you have to
> license it to deploy applications. In order to have transactions, you
> have to use another commercial product that they bolt into MySQL --
> Sleepycat software's database. Now you have two license systems to
> worry about.
Just a correction - you need to use the InnoDB database engine, which is
free and GPL and bundled with MySQL.
Chris
Ron Mayer
If I were a naive middle manager in some company, would I rather
use:
(a) the database used by Yahoo, Cisco, and Sony?
(b) the database used by Shannon Med Center, Mohawk SW, Vanten Inc, and BASF.
Now suppose I told that same middle manager there was an open
source alternative:
(c) used by Lockheed Martin, Nasdaq, AOL, and Unisys.
As far as I can tell (5-minutes searching) (c) is PostgreSQL.
http://jobsearch.monster.com/jobsearch.asp?q=postgresql
http://www.hotjobs.com/cgi-bin/job-search?KEYWORDS=postgres
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=1002&dockey=xml/8/1/816e9b7e50ae92331bb5c47a791a589f@activejobs0&c=1
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=1002&dockey=xml/c/8/c8dc5841d18329c6c50b55f67a7ff038@activejobs0&c=1
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=1002&dockey=xml/1/6/168f30dc84b8f195d1fc35feb6a2f67a@activejobs0&c=1
"The Nasdaq Stock Market ... currently looking to fill the following
positions in Trumbull, CT...Some positions require knowledge of ...Postgre SQL.."
I'm not sure quite what it'd take to get the permission to use
these company's names, but surely we could have a list of links
to the job postings... I'd bet that one of monster, hotjobs,
and/or dice would even provide a datafeed of relevant jobs to
be posted on the postgresql.org site.
If we simply had a list of companies using postgresql highly visible
somewhere -- not necessarily a complex case study, just simple list
of "company X uses postgresql for Y" statements -- I think it would
go a long way. I'll contribute. InterVideo uses postgresql (for
running user surveys and some internal reporting and development tools).
Ron
PS: No offense to Shannon, Mohawk, Vanten, and yes, I know BASF is
an awesome company. But they're all, even BASF, less of
a household name than Sony,Yahoo,Cisco,AOL,Nasdaq,Lockheed.
cbbr...@cbbrowne.com
> There are clearly places where PostgreSQL does have a distinct
> advantage. Price a 1000 user system for SQL*Server and PostgreSQL and
> you will see that we can hire a couple of DBA's just for the price
> difference. Since you can purchase PostgreSQL support, that is no
> longer a significant advantage for MS.
Start looking at "Enterprise" licenses for any of the big guys and the
pricing does get pretty scary.
> And about MySQL: It's also commercial. You are not supposed to use it
> except for a single machine for personal use unless you are a
> non-profit organization or unless absolutely everything you do is
> GPL[1].
On the one hand, if they are calling it "Open Source", then this is NOT
a fair statement.
On the other hand, if you look at their web site, they certainly do tip
their hat to the FUD/Paranoia about the "infectiveness" of the GPL.
They don't expressly say:
"Yes, you should be paranoid about the GPL because it infects anything
it ever touches with some frightening license virus worse than SARS."
Instead, they loudly use the line "... for users who prefer not to be
restricted by the terms of the GPL", of course, neither confirming or
denying any particular paranoia about what the impact of those terms may
or may not be.
> Hence, you have to license it to deploy applications. In order to
> have transactions, you have to use another commercial product that
> they bolt into MySQL -- Sleepycat software's database. Now you have
> two license systems to worry about.
Incorrect. You have to use another commercial product that they bolt
onto MySQL -- InnoDB, from the Norwegian company, Innobase.
<http://www.innodb.com/>
Sleepycat DB was used to prototype the notion of having transactions,
but since that introduces Yet Another Continent to the set of licensing
complications, and probably wasn't sufficiently 'in their interests,'
it's not the Preferred Transactional Engine...
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://cbbrowne.com/info/oses.html
Rules of the Evil Overlord #217. "If I'm wearing the key to the hero's
shackles around my neck and his former girlfriend now volunteers to
become my mistress and we are all alone in my bedchamber on my bed and
she offers me a goblet of wine, I will politely decline the offer."
<http://www.eviloverlord.com/>
Jeff Davis
>
> And about MySQL:
> It's also commercial. You are not supposed to use it except for a
> single machine for personal use unless you are a non-profit organization
> license it to deploy applications. In order to have transactions, you
> have to use another commercial product that they bolt into MySQL --
> Sleepycat software's database. Now you have two license systems to
> worry about.
>
> SQL*Server is closed. You have to rely on MS to fix any problems that
> crop up. MySQL has a very restrictive license [for those who might
> happen to bother to read such things] for both modifications to the code
> and also redistribution of applications.
>
> [1] I realize that people cheat on this all the time. In theory, they
> could all go to jail for it. It is certainly not a risk I would be
> willing to take. I have also bumped into people who had no idea that
> commercial use requires a commercial license for MySQL. There are
> probably lots of people in that boat too.
Can you point me to the relevent portions of the license?
I tried to go through the license, but it basically seemed free (as in GPL) to
me. My impression is that you can't statically link Sleepycat's Berkeley DB
with software unless it is released under a free license (reasonable, kind of
like the GPL, if you consider that reasonable). They sell a commercial
version, which allows you to statically link it. I sort of get the same idea
from MySQL: as long as you aren't trying to distribute it, you're fine (even
in-house changes).
Also, aren't mysql and sleepycat in the standard distribution of Debian? I
would think the debian developers would be interested to know if the likes of
sleepycat and mysql don't abide by the DFSG. That's actually one of the
things I've always liked about Debian: read one set of guidelines, and trust
the developers to ensure compliance across the entire OS (as long as you stay
our of non-free). At least, so I thought...
Regards,
Jeff Davis
Dann Corbit
> From: Jeff Davis [mailto:jdavis...@empires.org]=20
> Sent: Monday, April 14, 2003 10:07 PM
> To: pgsql-...@postgresql.org
> Subject: Re: [HACKERS] Are we losing momentum?
>=20
>=20
> >
> > And about MySQL:
> > single machine for personal use unless you are a non-profit=20
> > organization or unless absolutely everything you do is=20
> GPL[1]. Hence,=20
> > you have to license it to deploy applications. In order to have=20
> > transactions, you have to use another commercial product that they=20
> > bolt into MySQL -- Sleepycat software's database. Now you have two=20
> > license systems to worry about.
> >
> > SQL*Server is closed. You have to rely on MS to fix any=20
> problems that=20
> > crop up. MySQL has a very restrictive license [for those who might=20
> > happen to bother to read such things] for both modifications to the=20
> > code and also redistribution of applications.
> >
> theory, they=20
> > could all go to jail for it. It is certainly not a risk I would be=20
> > willing to take. I have also bumped into people who had no=20
> idea that=20
> > commercial use requires a commercial license for MySQL. There are=20
> > probably lots of people in that boat too.
> Can you point me to the relevent portions of the license?
> I tried to go through the license, but it basically seemed=20
> free (as in GPL) to=20
> me. My impression is that you can't statically link=20
> Sleepycat's Berkeley DB=20
> with software unless it is released under a free license=20
> (reasonable, kind of=20
> like the GPL, if you consider that reasonable). They sell a=20
> commercial=20
> version, which allows you to statically link it.
As another poster pointed out, Sleepycat is no longer the transaction
engine of choice for MySQL.
Here is the sleepycat license:
http://www.sleepycat.com/docs/sleepycat/license.html
Here is a fragment:
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software. The source code
* must either be included in the distribution or be available for no
* more than the cost of distribution plus a nominal fee, and must be
* freely redistributable under reasonable conditions. For an
* executable file, complete source code means the source code for
all
* modules it contains. It does not include source code for modules
or
* files that typically accompany the major components of the
operating
* system on which the executable file runs.
We also find this on their web site:
http://www.sleepycat.com/company/legal.shtml
Which says (among other things):
=20
"Sleepycat Software Legal Notices
Copyright (c) 1990-2003 Sleepycat Software, Inc., 118 Tower Rd.,
Lincoln, MA 01773, U.S.A. All Rights Reserved.
This product and publication is protected by copyright and distributed
under licenses restricting its use, copying and distribution. Permission
to use this publication or portions of this publication is granted by
Sleepycat Software provided that the above copyright notice appears in
all copies and that use of such publications is for non-commercial use
only and no modifications of the publication is made."
Notice the phrase 'non-commercial use only'
> I sort of=20
> get the same idea=20
> from MySQL: as long as you aren't trying to distribute it,=20
> you're fine (even=20
> in-house changes).
>=20
> Also, aren't mysql and sleepycat in the standard distribution=20
> of Debian? I=20
> would think the debian developers would be interested to know=20
> if the likes of=20
> sleepycat and mysql don't abide by the DFSG. That's actually=20
> one of the=20
> things I've always liked about Debian: read one set of=20
> guidelines, and trust=20
> the developers to ensure compliance across the entire OS (as=20
> long as you stay=20
> our of non-free). At least, so I thought...
For MySQL, form here
http://www.mysql.com/doc/en/Using_the_MySQL_software_under_a_commercial_
license.html we have this:
"1.4.3.1 Using the MySQL Software Under a Commercial License
The GPL license is contagious in the sense that when a program is linked
to a GPL program all the source code for all the parts of the resulting
product must also be released under the GPL. If you do not follow this
GPL requirement, you break the license terms and forfeit your right to
use the GPL program altogether. You also risk damages.=20
You need a commercial license:=20
When you link a program with any GPL code from the MySQL software and
don't want the resulting product to be licensed under GPL, perhaps
because you want to build a commercial product or keep the added non-GPL
code closed source for other reasons. When purchasing commercial
licenses, you are not using the MySQL software under GPL even though
it's the same code.=20
When you distribute a non-GPL application that only works with the MySQL
software and ship it with the MySQL software. This type of solution is
considered to be linking even if it's done over a network.=20
When you distribute copies of the MySQL software without providing the
source code as required under the GPL license.=20
When you want to support the further development of the MySQL database
even if you don't formally need a commercial license. Purchasing support
directly from MySQL AB is another good way of contributing to the
development of the MySQL software, with immediate advantages for you.
See section 1.4.1 Support Offered by MySQL AB.=20
If you require a license, you will need one for each installation of the
MySQL software. This covers any number of CPUs on a machine, and there
is no artificial limit on the number of clients that connect to the
server in any way.=20
For commercial licenses, please visit our website at
http://www.mysql.com/products/licensing.html. For support contracts, see
http://www.mysql.com/support/. If you have special needs or you have
restricted access to the Internet, please contact our sales staff via
e-mail at sa...@mysql.com."
------------------------------------------------------------------------
-----
Note phrases like "you want to build a commercial product" and "When you
distribute a non-GPL application that only works with the MySQL software
and ship it with the MySQL software. This type of solution is considered
to be linking even if it's done over a network."
Shridhar Daithankar
> Regardless, I'm still of the opinion that if you build it, they will come
> -- particularly costly features like replication, PITR, etc. But maybe
> that is what the BSDs say about Linux?
That is an unfair comparison. The technical differences between BSD and linux
are not as much as postgresql and mysql. Besides what is the parallel of SQL
standard in OS world? POSIX? And both BSD/linux are doing fine sitting next
to each other on that.
After porting my small application in less than half an hour from linux to
freeBSD and vice versa, I really do not agree with that comment. Not even in
the spirit of it.
Shridhar
Oliver Elphick
> Also, aren't mysql and sleepycat in the standard distribution of Debian? I
> would think the debian developers would be interested to know if the likes of
> sleepycat and mysql don't abide by the DFSG. That's actually one of the
> things I've always liked about Debian: read one set of guidelines, and trust
> the developers to ensure compliance across the entire OS (as long as you stay
I looked at the copyright information on the mysql-server package in
Debian and also at http://www.mysql.com/doc/en/MySQL_licenses.html:
The MySQL documentation is in non-free (and is not therefore officially
part of Debian). MySQL itself is GPL, so you can do what you like with
it, whatever FUD their website puts out, so long as you make your source
code available. If you want to fork MySQL, you can!
Sleepycat is free so long as source code is released.
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"And they questioned Him, saying "...Is it lawful for
us to pay taxes to Caesar, or not? ...And He said to
them "...render to Caesar the things that are
Caesar's, and to God the things that are God's."
Luke 20:21,22,25
Tom Lane
> That's a pretty reasonable thought. I work for a shop that sells
> Postgres support, and even we install MySQL for the Q&D ticket tracking
> system we recommend because we can't justify the cost to port it to
> postgres. If the postgres support were there, we would surely be using it.
> How to fix such a situation, I'm not sure. "MySQL Compatability Mode,"
> anyone? :-)
What issues are creating a compatibility problem for you?
regards, tom lane
Kevin Brown
> Curt Sampson <c...@cynic.net> writes:
> > That's a pretty reasonable thought. I work for a shop that sells
> > Postgres support, and even we install MySQL for the Q&D ticket tracking
> > system we recommend because we can't justify the cost to port it to
> > postgres. If the postgres support were there, we would surely be using it.
>
> > How to fix such a situation, I'm not sure. "MySQL Compatability Mode,"
> > anyone? :-)
>
> What issues are creating a compatibility problem for you?
Erm...reserved words? "Freeze" is a reserved word, for instance, and
that actually bit me when converting an MS-SQL database...
I have no problem with reserved words in principle, at least when they
refer to the SQL-standard commands and their options, but it's not
clear that turning options (such as FREEZE) for PG-specific commands
(such as VACUUM) into reserved words is a good idea. But it may not
be possible to avoid it, unfortunately. :-(
--
Kevin Brown ke...@sysexperts.com
Curt Sampson
> > How to fix such a situation, I'm not sure. "MySQL Compatability Mode,"
> > anyone? :-)
>
> What issues are creating a compatibility problem for you?
We can't unthinkingly point the product at a PostgreSQL server and
have it Just Work. So all we really need is full SQL and wire-protocol
compatability. :-)
cjs
--
Curt Sampson <c...@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
Dave Page
> -----Original Message-----
> From: Ron Mayer [mailto:r...@intervideo.com]=20
> Sent: 15 April 2003 05:38
> To: pgsql-...@postgresql.org
> Cc: r...@intervideo.com
> Subject: Re: [HACKERS] Are we losing momentum?
>=20
>=20
> IMVHO it's reference customers/users more than books & windows ports.
>=20
> If I were a naive middle manager in some company, would I rather
> use:
>=20
> (a) the database used by Yahoo, Cisco, and Sony?
Cisco use PostgreSQL:
http://www.cisco.com/en/US/products/sw/voicesw/ps4371/products_user_guid
e_chapter09186a00800c252c.html
:-)
But I see your point...
Regards, Dave.
mlw
Christopher Kings-Lynne wrote:
>>That's a pretty reasonable thought. I work for a shop that sells
>>Postgres support, and even we install MySQL for the Q&D ticket tracking
>>system we recommend because we can't justify the cost to port it to
>>postgres. If the postgres support were there, we would surely be using it.
>>
>>How to fix such a situation, I'm not sure. "MySQL Compatability Mode,"
>>anyone? :-)
>>
>>
>
>The real problem is PHP. PHP is just the cruftiest language ever invented (trust me, I use it every day). The PHP people are totally dedicated to MySQL, to the exclusion of all rational thought (eg. When I asked Rasmas at a conference about race conditions in his replicated setup, he replied "it's never going to happen - MySQL's replication is just too fast...).
>
>
>
Hey! don't go knocking PHP, it is probably one of the most flexible and
easy to use systems around. I have done several fairly large projects
with PHP and while it is an "ugly" environment, it performs well enough,
has a very usable extension interface, it is quick and easy to even
large projects done.
As for MySQL, there are two things that PostgreSQL does not do, and
probably can not do to support MySQL:
(1) REPLACE INTO (I think that's the name) which does either an insert
or update into a table depending on the existence of a row. I was told
that this was impossible.
(2) MySQL returns a value on insert which is usually usable, for instance,
insert into mytable (x,y,z) values(1,2,3);
select rowid from mytable where x=1 and y=2 and z=3;
I have had many discussions with MySQL people, and one common thread
exists. People who use MySQL do not usually understand databases all
that well. Arguments about *why* it is a horrible database and barely
SQL at all, fall on deaf ears. They don't understand PostgreSQL, they
complain that it is "too big." They complain that it is "too much,"
MySQL is all they need. They complain that it is "too hard" to use.
All of these things are largely imagined. PostgreSQL is not much bigger
than MySQL, in fact, the difference is negligible with regards to
average system capability these days. It isn't any more difficult to
use, its just a little different. They, however, feel safe with MySQL.
MySQL is the Microsoft of databases, everyone uses it because everyone
uses it, not because it is better or even adequate.
We need to take projects like Bugzilla (Did RH ever release the PG
version or am I way out of date?) and port them to PostgreSQL. We need
to write free articles for Linux and IT magazines about how to take a
MySQL project over to PostgreSQL easily, why PostgreSQL is much better
than MySQL, lastly we have to play the MySQL benchmark game .. we need
to create a Benchmark program that clearly shows how PostgreSQL compares
to MySQL.
mlw
Mike Mascari wrote:
>cbbr...@cbbrowne.com wrote:
>
>
>> b) We recently were considering how we'd put a sharable Windows box
>> in, at the office. Were considering using VNC to allow it to be
>> accessible. Then someone thought to read the license, only to
>> discover that the license pretty much expressly forbids running
>> "foreign, competing applications" on the platform.
>>
>>It seems pretty plausible that the net result of further development
>>will be platforms that are actively hostile to foreign software.
>>
>>If I suggested that the licensing of Win2003 would expressly forbid
>>installing PostgreSQL, people would rightly accuse me of being a
>>paranoid conspiracy theorist.
>>
>>
>
>I think you are a paranoid conspiracy theorist. :-)
>
>Mike Mascari
>mas...@mascari.com
>
>
"Just because you're paranoid does not mean they're not out to get you."
Henry Kissinger.
Tatsuo Ishii
> easy to use systems around. I have done several fairly large projects
> with PHP and while it is an "ugly" environment, it performs well enough,
> has a very usable extension interface, it is quick and easy to even
> large projects done.
Right. PHP is our friend. In Japan Apache+PHP+PostgreSQL combo is the
standard for Web systems. Very few people uses Apache+PHP+MySQL.
--
Tatsuo Ishii
Keith Bostic
>
> We also find this on their web site:
> http://www.sleepycat.com/company/legal.shtml
> Which says (among other things):
>
>
> Copyright (c) 1990-2003 Sleepycat Software, Inc., 118 Tower Rd.,
> Lincoln, MA 01773, U.S.A. All Rights Reserved.
>
> This product and publication is protected by copyright and distributed
> under licenses restricting its use, copying and distribution. Permission
> to use this publication or portions of this publication is granted by
> Sleepycat Software provided that the above copyright notice appears in
> all copies and that use of such publications is for non-commercial use
> only and no modifications of the publication is made."
>
> Notice the phrase 'non-commercial use only'
This isn't quite right. This legal notice clearly applies to the
"publication", distinct from the product, or software. We don't
want our documentation modified and published by other people, we
wanted to reserve the right to publish it ourselves.)
Sleepycat's software is under an OpenSource license, and you can't
exclude commercial use in an OpenSource license.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bos...@sleepycat.com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
Tom Lane
> We need to take projects like Bugzilla (Did RH ever release the PG
> version or am I way out of date?) and port them to PostgreSQL.
See http://bugzilla.redhat.com/bugzilla/ ... note icon at bottom ...
note tarball offered in News ...
regards, tom lane
Robert Treat
> Christopher Kings-Lynne wrote:
> >
> >The real problem is PHP. PHP is just the cruftiest language ever invented
> > (trust me, I use it every day). The PHP people are totally dedicated to
> > MySQL, to the exclusion of all rational thought (eg. When I asked
> > Rasmas at a conference about race conditions in his replicated
> > setup, he replied "it's never going to happen - MySQL's replication
> > is just too fast...).
> >
> easy to use systems around. I have done several fairly large projects
> with PHP and while it is an "ugly" environment, it performs well enough,
> has a very usable extension interface, it is quick and easy to even
> large projects done.
>
The problem is the marriage of PHP and MySql. I've always held the
notion that early on several of the php developers, being windows
hackers, needed an open source database that would run on windows. They
picked mysql (which was probably their best option at the time) and
mysql rode on the shoulders php's success.
> As for MySQL, there are two things that PostgreSQL does not do, and
> probably can not do to support MySQL:
>
> (1) REPLACE INTO (I think that's the name) which does either an insert
> or update into a table depending on the existence of a row. I was told
> that this was impossible.
>
> (2) MySQL returns a value on insert which is usually usable, for instance,
> insert into mytable (x,y,z) values(1,2,3);
> select rowid from mytable where x=1 and y=2 and z=3;
>
I'm pretty sure I've seen people create db functions to duplicate these
features, but admittedly that would be more complicated.
<snip>
>
> We need to take projects like Bugzilla (Did RH ever release the PG
> version or am I way out of date?) and port them to PostgreSQL. We need
> to write free articles for Linux and IT magazines about how to take a
> MySQL project over to PostgreSQL easily, why PostgreSQL is much better
> than MySQL,
Red Hat actually did do this, and does make the source available. One
problem I found with porting of mysql apps is that those apps tend to do
a lot of dump things to make up for mysql's missing features. Unless
you really are willing to fork the code and then maintain it as a new
project, porting applications gets somewhat futile.
Robert Treat
scott.marlowe
>
>
> Christopher Kings-Lynne wrote:
>
> >>That's a pretty reasonable thought. I work for a shop that sells
> >>Postgres support, and even we install MySQL for the Q&D ticket tracking
> >>system we recommend because we can't justify the cost to port it to
> >>postgres. If the postgres support were there, we would surely be using it.
> >>
> >>How to fix such a situation, I'm not sure. "MySQL Compatability Mode,"
> >>anyone? :-)
> >>
> >>
> >
> >The real problem is PHP. PHP is just the cruftiest language ever invented (trust me, I use it every day). The PHP people are totally dedicated to MySQL, to the exclusion of all rational thought (eg. When I asked Rasmas at a conference about race conditions in his replicated setup, he replied "it's never going to happen - MySQL's replication is just too fast...).
> >
> >
> >
> Hey! don't go knocking PHP, it is probably one of the most flexible and
> easy to use systems around. I have done several fairly large projects
> with PHP and while it is an "ugly" environment, it performs well enough,
> has a very usable extension interface, it is quick and easy to even
> large projects done.
I would say that compared to Perl, TCL, and many other scripting languages
that PHP is actually a far better and more logically designed language.
the way it handles arrays and global vars is the way every language
should.
Kurt Roeckx
> Bruce Momjian <pg...@candle.pha.pa.us> writes:
> > Several people have asked if we are losing momentum.
>
> yesterday, and could not help but notice how many books had "MySQL" in
> the title. I didn't notice a single Postgres title (though I did not
> look hard, since I was just passing through the computer area).
2 local stores here:
One has 11 PostgresQL books and 40 MySQL, the other had 5 on
PostgresQL and 23 about MySQL.
Kurt
Lamar Owen
> We need to take projects like Bugzilla (Did RH ever release the PG
> version or am I way out of date?) and port them to PostgreSQL.
http://bugzilla.redhat.com/download/rh-bugzilla-pg-LATEST.tar.gz
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Bruce Momjian
> narrow the bookshelf gap a little, at least. Any wannabee authors
> out there? (And Bruce, your book is due for a second edition...)
Agreed. I will contact the publisher and get started, maybe in the
summer.
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian
Having good reference sites is important, and I could list as many
impressive ones as MySQL, but who has time to hunt around and get
permission to list them --- I will tell you who --- the MySQL marketing
guys, while the PostgreSQL guys don't. :-(
---------------------------------------------------------------------------
Ron Mayer wrote:
> IMVHO it's reference customers/users more than books & windows ports.
>
> If I were a naive middle manager in some company, would I rather
> use:
>
> (a) the database used by Yahoo, Cisco, and Sony?
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majo...@postgresql.org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
Bruce Momjian
> On Tuesday 15 April 2003 05:48, you wrote:
> > Regardless, I'm still of the opinion that if you build it, they will come
> > -- particularly costly features like replication, PITR, etc. But maybe
> > that is what the BSDs say about Linux?
>
> That is an unfair comparison. The technical differences between BSD and linux
> are not as much as postgresql and mysql. Besides what is the parallel of SQL
> standard in OS world? POSIX? And both BSD/linux are doing fine sitting next
> to each other on that.
Agreed, Linux and BSD are pretty close --- but Linux used to be behind
BSD --- they caught up because both are open source. The big question
is whether MySQL (which isn't openly developed) will catch up to
PostgreSQL. And if they do catch up, will we have mind share parity by
that time?
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
Steve Wampler
> On Tuesday 15 April 2003 07:51, mlw wrote:
> > We need to take projects like Bugzilla (Did RH ever release the PG
> > version or am I way out of date?) and port them to PostgreSQL.
>
> http://bugzilla.redhat.com/download/rh-bugzilla-pg-LATEST.tar.gz
Of course, the installation instructions that come with it tell you
to install perl's interface to MySQL, not PostgreSQL. Sigh.
--
Steve Wampler <swam...@noao.edu>
National Solar Observatory
John Liu
the reputation of PostgreSQL is full featured.
Business chooses PostgreSQL is bacause PostgreSQL is close
to database like Oracle, reliable but without cost.
To compete with MySQL is not a good strategy, IMHO,
PostgreSQL needs to focus adding features such as
table partitioning like Oracle, needs to improve
the performance of subquery, etc. Those lack performance
features are the choke point (it's easy to get better performance
for a big table [~100 million] with partitions in oracle than
postgreSQL; it's a nightmare, a mess for using subquery in postgreSQL,
I can't wait 7.4's smarter on this).
If you really have a super product, don't you
worry user will not switch to it with no cost?
just some thoughts ...
johnl
ow
available.
One of the features that PostgreSql must have, IMHO, is support for
cross-db operations (queries, updates, deletes, inserts). 2PC and
cross-server stuff would be nice but it's not as important as simple
cross -db operations across databases on the same server. All major
comercial RDBMS (and even mySql!) support this but for Postgres. Sad.
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Rob Butler
New to the Hackers list, but long time lurker on the archives. Also a member of the Postgres-r list. Just thought I would join in now to give my opinions on this thread.
> One of the features that PostgreSql must have, IMHO, is support for
> cross-db operations (queries, updates, deletes, inserts). 2PC and
> cross-server stuff would be nice but it's not as important as simple
> cross -db operations across databases on the same server. All major
> comercial RDBMS (and even mySql!) support this but for Postgres. Sad.
I disagree, The cross-db operations would indeed be very nice to have, but you COULD make things work across DB's from within your application code if Postgres supported 2PC. Granted this would not be the best, but it could be done.
Also, if you want to start doing cross-db operations you will need 2PC to support this. While 2PC may not be needed to support cross-db operations on two db's on the same server, it would definetly be needed to do cross-db operations with db's on two separate servers. Why limit the cross-db operations only to db's on the same server?
Later
Rob
Sean Chittenden
> > will come -- particularly costly features like replication, PITR,
> > etc. But maybe that is what the BSDs say about Linux?
>
> That is an unfair comparison. The technical differences between BSD
> and linux are not as much as postgresql and mysql. Besides what is
> the parallel of SQL standard in OS world? POSIX? And both BSD/linux
> are doing fine sitting next to each other on that.
>
> linux to freeBSD and vice versa, I really do not agree with that
> comment. Not even in the spirit of it.
Yes, that is the joy of POSIX, ANSI, SUS, SUSv2, XPG*, etc. The
differences in the OS aren't visible at the user level and shouldn't
be (beyond the layout/management). That said, standards are great,
but all select()/poll() calls weren't created equal, just like all
SELECT statements weren't created equal. -sc
--
Sean Chittenden
Robert Treat
> IMHO, mySql 5.0 will put more pressure on PostgreSql, when it's
> available.
>
> cross-db operations (queries, updates, deletes, inserts). 2PC and
> cross-server stuff would be nice but it's not as important as simple
> cross -db operations across databases on the same server. All major
> comercial RDBMS (and even mySql!) support this but for Postgres. Sad.
>
dblink ?
Robert Treat
Mike Benoit
PostgreSQL, the whole "vacuum" issue always seems to come up. Some way
to get vacuum automated (and thus out of sight, out of mind) I think
would make great strides in making PG at least "seem" more friendly to
someone on the outside.
Shared hosting enviroments. I work for a web hosting company that offers
MySQL to all of its customers, our MySQL server has several thousand
databases on it, and I must say it works exceptionally well.
Creating users/databases/changing passwords is as simple as sending it a
couple queries from our Customer web interface, trouble shooting poor
queries takes seconds when using "mytop" (mtop), and tracking/billing
for disk usage is as simple as running "du /var/lib/mysql/*". I would
like to say the same things for PG, but I'm affrid I can't.
I think it all comes down to how simple PG is to setup and use on a
daily basis. This is what determines the size of its community. Even
just the simple things make a big difference. ie:
\dt
compared to:
show tables;
Yes, once you get over the "hump" PG is quite efficient, but you need to
understand it, and learn some small quriks first. With MySQL, you can
pretty much guess commands, and they often work! Not as much luck with
PG.
show indexes
show processlist
show columns from <table>
These are all easy/simple commands that make sense to someone who is
just learning the ropes. Short abbreviated, commands are great for the
experts, but can greatly discourage newbies.
On Mon, 2003-04-14 at 18:52, Brent Verner wrote:
> Gretings!
>
> [2003-04-14 19:54] Tom Lane said:
> | Bruce Momjian <pg...@candle.pha.pa.us> writes:
> | > Several people have asked if we are losing momentum.
>
> | I don't know what we can do about it, other than maybe push harder to
> | get some more PG titles into O'Reilly's catalog ... that would help
> | narrow the bookshelf gap a little, at least. Any wannabee authors
> | out there? (And Bruce, your book is due for a second edition...)
>
> I've wanted to pipe up in a few of these "popularity"
> discussions in the past. Seeing how I can't make time to
> participate in any other meaningful capacity, I'll share
> my thoughts on _why_ mysql has the mindshare.
>
>
> Applications, specifically applications that _use_ mysql.
>
>
> A quick search over at freshmeat returns 1044 results for
> "mysql" and 260 for "postgresql". Before this turns into a
> cause/effect discussion, I want to state up front that the
> real "effect" of this is that someone is 4 times as likely to
> download an application that uses mysql. Sure, many are
> "trivial" applications, but I posit that it is _specifically_
> these "trivial" applications that inoculate the uninitiated
> with the belief that mysql is suitable for use in real, albeit
> trivial applications. Additionally, it these rudimentary
> applications that will be studied by many as the way to write
> a database application.
>
> It is all good and well that postgres /can/ do, but until
> the application developers see that those features are
> valuable enough to forgo mysql support, they'll write the
> application to support whatever database is most likely to
> _already_ be installed, which will be mysql. Granted,
> many developers will also try to support multiple dbs via
> the language's db api, but this leaves the less-supported
> dbs in an even worse position; being relegated to an
> "might work with XXX database". When anxious user learns
> that "might" currently means "doesn't," the second-string
> database looks even worse in the eyes of the user.
>
> How to solve this problem? This is the hard part, but
> luckily ISTM that there are a few ways to succeed. Neither
> of which involves marketing or writing books.
>
> 1) become active in the "also supports postgres" projects,
> and add features that are made available _because_ of
> postgres' superiority. Eventually, market pressure
> for the cool feature(s) will lead users to choose
> postgres, and mysql could be relegated to the "also
> runs on mysql, with limited featureset"
> 2) take a popular project that uses mysql, fork it, and
> add features that can only be implemented using posgres.
> 3) release that super-cool code that you've been hacking
> on for years, especially if it is a "trivial" app.
> 4) convince your employer that it would be _beneficial_ to
> them to release, as open source, the internal app(s) you've
> developed, using postgres-specific features. (This is
> about all I can claim to be doing at this point in my
> indentured servitude, and I can't say I'm doing a good
> job... :-/)
>
> I'm sure this idea is not original, but I'm also sure that
> it _is_ the answer to gaining market^Wmindshare in this
> database market.
>
> (I must apologize in advance, that I might not have time
> to even follow this thread, in fact, I hope that instead of
> replying to this, the potential respondent might consider
> helping to increase the number of apps that require postgres
> :-)
>
> wishing-I-could-contribute-more-ly yours,
> brent
--
Best Regards,
Mike Benoit
NetNation Communications Inc.
Systems Engineer
Tel: 604-684-6892 or 888-983-6600
---------------------------------------
Disclaimer: Opinions expressed here are my own and not
necessarily those of my employer
ow
> I disagree, The cross-db operations would indeed be very nice to
> have, but you COULD make things work across DB's from within your
> application code if Postgres supported 2PC. Granted this would not
> be the best, but it could be done.
Sure, anything could be done given time and money. OTOH, why would one
want to hand-code joins between tables in different dbs, configure
multiple connection pools, etc when all that can be avoided with a
RDBMS that supports cross-db operations? And since mySql supports
cross-db ops now, mySql could become a very intersting option when they
implement all the features they promissed for version 5.0
> Also, if you want to start doing cross-db operations you will need
> 2PC to support this. While 2PC may not be needed to support cross-db
> operations on two db's on the same server, it would definetly be
> needed to do cross-db operations with db's on two separate servers.
> Why limit the cross-db operations only to db's on the same server?
I'm not saying Postgres has to limit itself to cross-db ops on the same
server only. However, if it's much simpler to implement then why not
start there? Cross-db ops have been on the Postgres TODO list for
several years now and, AFAICT, it does not appear that they will be
available any time soon. Thanks
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Tom Lane
> On Tue, 2003-04-15 at 13:30, ow wrote:
>> One of the features that PostgreSql must have, IMHO, is support for
>> cross-db operations (queries, updates, deletes, inserts). 2PC and
>> cross-server stuff would be nice but it's not as important as simple
>> cross -db operations across databases on the same server. All major
>> comercial RDBMS (and even mySql!) support this but for Postgres. Sad.
> dblink ?
I'm of the opinion that the availability of schemas solves most of the
problems that people say they need cross-database access for. If you
want cross-database access, first say why putting your data into several
schemas in a single database doesn't get the job done for you.
(Obviously, this only addresses cases where you'd have put the multiple
databases under one postmaster, but that's the scenario people seem to be
concerned about.)
regards, tom lane
Oliver Elphick
> Hello all,
>
> New to the Hackers list, but long time lurker on the archives. Also a member of the Postgres-r list. Just thought I would join in now to give my opinions on this thread.
>
> > cross-db operations (queries, updates, deletes, inserts). 2PC and
> > cross-server stuff would be nice but it's not as important as simple
> > cross -db operations across databases on the same server. All major
> > comercial RDBMS (and even mySql!) support this but for Postgres. Sad.
>
> have, but you COULD make things work across DB's from within your
> application code if Postgres supported 2PC. Granted this would not be
> the best, but it could be done.
In any case, we effectively have the equivalent of MySQL's
cross-database access in schemas, which MySQL does not have. So rather
than treating it as a problem we should just advertise it as a
terminological difference.
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"And they questioned Him, saying "...Is it lawful for
us to pay taxes to Caesar, or not? ...And He said to
them "...render to Caesar the things that are
Caesar's, and to God the things that are God's."
Luke 20:21,22,25
Dann Corbit
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]=20
> Sent: Tuesday, April 15, 2003 12:17 PM
> To: Robert Treat
> Cc: ow; pgsql-...@postgresql.org
> Subject: Re: [HACKERS] Are we losing momentum?=20
>=20
> support for=20
> >> cross-db operations (queries, updates, deletes, inserts). 2PC and=20
> >> cross-server stuff would be nice but it's not as important=20
> as simple=20
> >> cross -db operations across databases on the same server.=20
> All major=20
> >> comercial RDBMS (and even mySql!) support this but for=20
> Postgres. Sad.
>=20
> > dblink ?
>=20
> I'm of the opinion that the availability of schemas solves=20
> most of the problems that people say they need cross-database=20
> access for. If you want cross-database access, first say why=20
> putting your data into several schemas in a single database=20
> doesn't get the job done for you.
Because you had to buy several packages to solve your problems. You
have (perhaps) Peoplesoft for HR, and SAP for CRM, Supply Chain and some
others. You bought an Oracle package for manufacturing, and you run
your web server on PostgreSQL. Nearly every large business has this
problem.
=20
> (Obviously, this only addresses cases where you'd have put=20
> the multiple databases under one postmaster, but that's the=20
> scenario people seem to be concerned about.)
Heterogenius database access is another realistic scenario. In order to
solve this, you would need to be able to specify an ODBC, JDBC or OLEDB
table as a partner in transactions.
Tom Lane
> Because you had to buy several packages to solve your problems.
And?
ISTM you can put 'em in the same database anyway.
regards, tom lane
ow
> I'm of the opinion that the availability of schemas solves most of
> the problems that people say they need cross-database access for. If
> you want cross-database access, first say why putting your data into
> several schemas in a single database doesn't get the job done for
you.
Some databases contain lots of data, e.g. dbs that contain historical
data. No one wants to have one HUGE db that runs all company's apps,
takes hours (if not days) to recover and when this huge db goes down
none of the apps is available.
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
---------------------------(end of broadcast)---------------------------
Dann Corbit
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]=20
> Sent: Tuesday, April 15, 2003 12:35 PM
> To: Dann Corbit
> Cc: Robert Treat; ow; pgsql-...@postgresql.org
> Subject: Re: [HACKERS] Are we losing momentum?=20
>=20
>=20
> >> most of the problems that people say they need cross-database=20
> >> access for. If you want cross-database access, first say why=20
> >> putting your data into several schemas in a single database=20
> >> doesn't get the job done for you.
> > Because you had to buy several packages to solve your problems.
> And?
>=20
> ISTM you can put 'em in the same database anyway.
Sure you can. It's not easy of course. That's one of the things that
CONNX software does (I work for CONNX Solutions Inc.). Certainly, the
PostgreSQL group could accomplish the same thing, if they put their mind
to it.
I can easily join PostgreSQL tables to Oracle tables and insert the
result set into DB/2. No programs, no extracts. Just a SQL query.
Neil Conway
> Some databases contain lots of data, e.g. dbs that contain historical
> data. No one wants to have one HUGE db that runs all company's apps,
> takes hours (if not days) to recover and when this huge db goes down
> none of the apps is available.
Are you talking about queries between databases on the same postmaster
(i.e. running under the same PostgreSQL installation), or queries
between postmasters running on different systems? If the former, I don't
see how putting your data into multiple schemas in a single database is
significantly less reliable than putting it into multiple databases.
Cheers,
Neil
Michael Paesold
> Shared hosting enviroments. I work for a web hosting company that offers
> MySQL to all of its customers, our MySQL server has several thousand
> databases on it, and I must say it works exceptionally well.
>
> Creating users/databases/changing passwords is as simple as sending it a
> couple queries from our Customer web interface, trouble shooting poor
> queries takes seconds when using "mytop" (mtop), and tracking/billing
> for disk usage is as simple as running "du /var/lib/mysql/*". I would
> like to say the same things for PG, but I'm affrid I can't.
At least in the latest versions, things are quite easy.
User/database administration?
CREATE USER someuser ENCRYPTED PASSWORD '...' NOCREATEDB NOCREATEUSER;
CREATE DATABASE someuser OWNER someuser ENCODING 'UNICODE';
Disk usage account? Use contrib/dbsize (README for easy setup)
SELECT database_size('someuser');
Done.
Poor queries -> query stats?
Of course, some things are easier in MySQL. On the other hand, what about
InnoDB, "du /var/lib/mysql/*" won't help much...
I just wanted to show that PostgreSQL administration is not that hard in a
hosting environment.
Regards,
Michael Paesold
ow
> Are you talking about queries between databases on the same
> postmaster
> (i.e. running under the same PostgreSQL installation),
Yes
> or queries
> between postmasters running on different systems? If the former, I
> don't
> see how putting your data into multiple schemas in a single database
> is
> significantly less reliable than putting it into multiple databases.
I disagree. For example, suppose you have
app12 that uses db1 and db2,
app23 that uses db2 and db3,
app3 that uses db3.
If db3 goes down then app12 is not affected, app23 could be partially
affected (e.g. user may not be able to run historic queries) and app3
is completely unavailable. This is definitely better than all three
apps are down. Besides, having one huge db makes everything more
difficult and requires (much) more time for backups, restores, etc.
Every major RDBMS vendor (and mySql) finds this feature important and
they support it. Hope Postgresql will too.
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Ron Mayer
Dann wrote:
>Sure you can. It's not easy of course. That's one of the things that
>CONNX software does (I work for CONNX Solutions Inc.). Certainly, the
>PostgreSQL group could accomplish the same thing, if they put their mind
>to it.
>
>I can easily join PostgreSQL tables to Oracle tables and insert the
>result set into DB/2. No programs, no extracts. Just a SQL query.
Very interesting... I was just in a conversation here at work about
joining data from an oracle system with data in a postgresql
system...
FWIW, Oracle has something called "Oracle Generic Connectivity"
and "Oracle Transparent Gateways" that do similar.
http://otn.oracle.com/products/oracle9i/datasheets/gateways/gateway_rel2_ds.html
"Oracle Generic Connectivity and Oracle Transparent Gateways provide
the ability to transparently access data in non-Oracle systems from
an Oracle environment....
...Oracle Generic connectivity makes it possible to access low-end
data stores such as Foxpro, Access, dBase and non-relational targets
like Excel. ...
...Oracle has transparent gateways to many sources, Sybase, Informix,
Microsoft SQL Server, Ingres, Teradata to name a few."
I was mildly disapointed I didn't see PostgreSQL on the list. 1/2 :-) 1/2 :-|
Is this similar to what CONNX does?
Ron
Dann Corbit
> From: Ron Mayer [mailto:r...@intervideo.com]=20
> Sent: Tuesday, April 15, 2003 3:07 PM
> To: Dann Corbit; Tom Lane
> Cc: Robert Treat; ow; pgsql-...@postgresql.org
> Subject: RE: [HACKERS] Are we losing momentum?=20
>=20
>=20
> Dann wrote:
> >Sure you can. It's not easy of course. That's one of the=20
> things that=20
> >CONNX software does (I work for CONNX Solutions Inc.).=20=20
> Certainly, the=20
> >PostgreSQL group could accomplish the same thing, if they put their=20
> >mind to it.
> >
> >I can easily join PostgreSQL tables to Oracle tables and insert the=20
> >result set into DB/2. No programs, no extracts. Just a SQL query.
> Very interesting... I was just in a conversation here at=20
> work about joining data from an oracle system with data in a=20
> postgresql=20
> system...
>=20
>=20
>=20
> FWIW, Oracle has something called "Oracle Generic Connectivity"=20
> and "Oracle Transparent Gateways" that do similar.
http://otn.oracle.com/products/oracle9i/datasheets/gateways/gateway_rel2
_ds.html
"Oracle Generic Connectivity and Oracle Transparent Gateways provide
the ability to transparently access data in non-Oracle systems from=20
an Oracle environment....
...Oracle Generic connectivity makes it possible to access low-end=20
data stores such as Foxpro, Access, dBase and non-relational targets=20
like Excel. ...
...Oracle has transparent gateways to many sources, Sybase, Informix,
Microsoft SQL Server, Ingres, Teradata to name a few."
I was mildly disapointed I didn't see PostgreSQL on the list. 1/2 :-)
1/2 :-| Is this similar to what CONNX does?=20=20
DRC responds: >>>>-----------------------------
CONNX joins anything to anything. We wrote several of our own ODBC
drivers (including a recent one for PostgreSQL in {soon to be released}
CONNX 8.9) and we also work with ODBC drivers or OLEDB sources written
by other folks. We import every data source into a central repository
of metadata called the CONNX CDD. After that, we can join across
systems transparent to the user.
We also have a data replication system that will mirror data from any
collection of database systems to a single target system or a collection
of target systems. We can replicate only the data that has changed,
which speeds up the synchronizations a lot.
Plenty of other stuff too. Those that are interested can cruise around
our web site. Probably off topic for the list at this point. Further
inquiries would probably be better as private emails.
DRC responds: <<<<-----------------------------
Robert E. Bruccoleri
problem with multi-database queries because of the following reasons:
1) When dealing with large databases, the use of multiple databases
reduces the risk of wiping out all the data, and reduces the recovery
time in case of accidents.
2) Multiple databases allow for different management policies on each
database, whereas schemas require some consistency across them all.
In a heterogeneous working environment, this is a signficant issue.
3) PostgreSQL should strive for heterogeneous multi-database queries,
so that applications currently using other systems could be slowly
migrated to PostgreSQL by moving portions of a database from other
vendors to PostgreSQL. In my work, the lack of PostgreSQL - Oracle
connectivity is a disabling impediment to wider PostgreSQL usage.
--Bob
+-----------------------------+------------------------------------+
| Robert E. Bruccoleri, Ph.D. | email: br...@acm.org |
| President, Congenomics Inc. | URL: http://www.congen.com/~bruc |
| P.O. Box 314 | Phone: 609 818 7251 |
| Pennington, NJ 08534 | |
+-----------------------------+------------------------------------+
Tom Lane
> I beg to differ with Tom Lane's opinion, but schemas do not solve the
> problem with multi-database queries because of the following reasons:
> 1) When dealing with large databases, the use of multiple databases
> reduces the risk of wiping out all the data, and reduces the recovery
> time in case of accidents.
> 2) Multiple databases allow for different management policies on each
> database, whereas schemas require some consistency across them all.
> In a heterogeneous working environment, this is a signficant issue.
> 3) PostgreSQL should strive for heterogeneous multi-database queries,
> so that applications currently using other systems could be slowly
> migrated to PostgreSQL by moving portions of a database from other
> vendors to PostgreSQL. In my work, the lack of PostgreSQL - Oracle
> connectivity is a disabling impediment to wider PostgreSQL usage.
Please keep in mind that I was replying to a poster who said "cross-db
queries on the same server (meaning same postmaster, for our purposes)
are trivial; why hasn't Postgres got them when everybody else does?"
Your above arguments are all good ones, but they presume a scenario that
is much different and *MUCH* harder to implement than local "cross
database" queries. My point is that schemas solve the same-server
problems that the original poster was interested in. I did not say,
nor mean, that there is no need for cross-server queries. But that is
a different problem. Today we can only offer dblink; maybe someday
SQL-MED.
regards, tom lane
---------------------------(end of broadcast)---------------------------
Tom Lane
> --- Neil Conway <ne...@samurai.com> wrote:
>> Are you talking about queries between databases on the same
>> postmaster
> Yes
> [snip]
> If db3 goes down then app12 is not affected, app23 could be partially
> affected (e.g. user may not be able to run historic queries) and app3
> is completely unavailable.
This is nonsense. There is no scenario where one DB "goes down" and
other DBs on the same postmaster remain up. There are advantages to
having separate DBs on one postmaster (like separate copies of the
system catalogs), but there's very little reliability differential
compared to a multi-schema approach.
regards, tom lane
---------------------------(end of broadcast)---------------------------
ow
> "cross-db
> queries on the same server (meaning same postmaster, for our
> purposes)
> are trivial; why hasn't Postgres got them when everybody else does?"
I think you're referring to one of my messages. If this is the case,
then you've misquoted me, that was not what I said.
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
ow
> other DBs on the same postmaster remain up. There are advantages to
> having separate DBs on one postmaster (like separate copies of the
> system catalogs), but there's very little reliability differential
> compared to a multi-schema approach.
Perhaps "goes down" is not the best term. You can replace it with "is
not available" (as in being restored, etc) if you like.
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
---------------------------(end of broadcast)---------------------------
Rob Butler
http://sourceforge.net/projects/bind-dlz
This is a patch for Bind 9.2.1 that allows all DNS data to be stored in an
external database. Makes DNS administration easy, and changes to DNS data
are reflected immediately. The project supports multiple databases now, but
the first one was postgres!
Later
Rob
cbbr...@cbbrowne.com
> --- Neil Conway <ne...@samurai.com> wrote:
> > Are you talking about queries between databases on the same
> > postmaster
>
> Yes
Based on your later comments, the answer seems to /actually/ be "No."
> > or queries
> > between postmasters running on different systems? If the former, I
> > don't
> > see how putting your data into multiple schemas in a single database
> > is
> > significantly less reliable than putting it into multiple databases.
>
> I disagree. For example, suppose you have
> app12 that uses db1 and db2,
> app23 that uses db2 and db3,
> app3 that uses db3.
>
> If db3 goes down then app12 is not affected, app23 could be partially
> affected (e.g. user may not be able to run historic queries) and app3
> is completely unavailable. This is definitely better than all three
> apps are down. Besides, having one huge db makes everything more
> difficult and requires (much) more time for backups, restores, etc.
>
> Every major RDBMS vendor (and mySql) finds this feature important and
> they support it. Hope Postgresql will too.
If it's all running as just one PostgreSQL instance, then if db1 goes down,
then, since it's the same postmaster as is supporting db2 and db3, they
necessarily go down as well.
The only way that you get to take down one DB without affecting the others is
for them NOT to be running as part of the same PG installation.
By the way, if you only have one PG instance, then you may very well find it
challenging to suitably parallelize all the loads/dumps of data. If you have
three disks, or three arrays, it may make a lot of sense to have separate PG
instances on each one, as that allows I/O to not need to interfere between
instances. (There are, admittedly, other ways of tuning this sort of thing,
such as moving WAL to a separate disk, or perhaps even specific table files,
identified by OID...)
But the most general ways of separating things out lead to having quite
separate DB instances. And when you've got that, it certainly is attractive
to have 2PC, as is available for the "expensive guys."
--
output = reverse("gro.mca@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/sap.html
You know that little indestructible black box that is used on
planes---why can't they make the whole plane out of the same
substance?
Sailesh Krishnamurthy
Tom> Please keep in mind that I was replying to a poster who said
Tom> "cross-db queries on the same server (meaning same
Tom> postmaster, for our purposes) are trivial; why hasn't
Tom> Postgres got them when everybody else does?"
BTW, DB2 doesn't have 'em either.
In DB2, you have Database -> Schema -> Objects
In DB2, you can of course have cross-schema queries but no cross-db
queries, unless you rig up the federated functionality to connect one
db to the other.
Much of the confusion stems from SQL-Server and Sybase having:
Database -> Objects
The Database is used to identify distinct schemas. I'm not sure if in
these systems they are physically separate entities (different lock
manager etc.)
--
Peace, at last ?
Sailesh
http://www.cs.berkeley.edu/~sailesh
Shridhar Daithankar
> From my experience, almost every time I talk to a MySQL supporter about
> PostgreSQL, the whole "vacuum" issue always seems to come up. Some way
> to get vacuum automated (and thus out of sight, out of mind) I think
> would make great strides in making PG at least "seem" more friendly to
> someone on the outside.
Agreed. But that is not an impossible issue for a DBA, is it? I mean some
learning is required but that can be done.
> Creating users/databases/changing passwords is as simple as sending it a
> couple queries from our Customer web interface, trouble shooting poor
> queries takes seconds when using "mytop" (mtop), and tracking/billing
> for disk usage is as simple as running "du /var/lib/mysql/*". I would
> like to say the same things for PG, but I'm affrid I can't.
Adding users, databases, password changes are as easy in postgresql. Tracking
disk usage is no different in postgresql barring additional step of using
oid2name to find out directory you want to du.
In fact I think postgresql is easier to use. Till date, I could never start
mysql by hand and get it behave sanely. pg_ctl or nohup postmaster has always
worked for me.
Besides postgresql is true to it's resource usage. You allocate 128MB of
shared buffers, and they are consumed. You stop postmaster and all the
buffers are back to system. With mysql, I found that large amount of memory
was never returned to system even after service shutdown. I hate black-boxes
on my system where I can not fathom into. Had to reboot the machine.
> I think it all comes down to how simple PG is to setup and use on a
> daily basis. This is what determines the size of its community. Even
> just the simple things make a big difference. ie:
>
> \dt
>
> compared to:
>
> show tables;
<I assume that show tables is not a standard SQL syntax>
That is very shallow view. \dt is a postgresql terminal client extension where
as show tables is part of mysql SQL offerings. Such brutal twisting of SQL
standards encourages dependence on mysql only features, flushing standard
compliance down the drain.
> Yes, once you get over the "hump" PG is quite efficient, but you need to
> understand it, and learn some small quriks first. With MySQL, you can
> pretty much guess commands, and they often work! Not as much luck with
> PG.
>
> show indexes
> show processlist
> show columns from <table>
>
> These are all easy/simple commands that make sense to someone who is
> just learning the ropes. Short abbreviated, commands are great for the
> experts, but can greatly discourage newbies.
Well, I might get flamed for this but let me clarify. I am not against
newbies. Everybody once was a newbie. But being a newbie, does not justify
reluctance to go thr. manuals. If you are reluctant to go thr. manuals., you
better hire a commercial support.
My advise has always been ,to read postgresql manual start to end before even
touching it. It takes a day to digest but pays off big later. When I started
postgresql back in 1999, I started on postgresql and SQL simalteneously.
Didn't have faintest idea, what any of those stand for. So I read the manual,
start to end in couple of days. In one day I could do things that worked as
expected.
RTFM is not an advice thrown to kick out newbies. It is ground fact that
everybody has to suffer thr. Borg transplants are not yet available here.
Shridhar
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Shridhar Daithankar
> Shridhar Daithankar wrote:
> > That is an unfair comparison. The technical differences between BSD and
> > linux are not as much as postgresql and mysql. Besides what is the
> > parallel of SQL standard in OS world? POSIX? And both BSD/linux are doing
> > fine sitting next to each other on that.
>
> BSD --- they caught up because both are open source. The big question
> is whether MySQL (which isn't openly developed) will catch up to
> PostgreSQL. And if they do catch up, will we have mind share parity by
> that time?
That is a tough question. But if we focus on enterprise features and reach
threshold in decision making circles, that would be great.
Mind share parity certainly matters. Bigger question is in which circles. I
would better put decision making circle as fist target.
Besides we won't sit still while mysql catches with us.
Shridhar
---------------------------(end of broadcast)---------------------------
Hannu Krosing
> > queries on the same server (meaning same postmaster, for our
> > purposes)
> > are trivial; why hasn't Postgres got them when everybody else does?"
>
> I think you're referring to one of my messages. If this is the case,
> then you've misquoted me, that was not what I said.
But what did you say then ?
I don't think that what MySQL has as databases is much different from
our schemas, so I too had some difficulty understandin what you were
complaing about
---------------
Hannu
ow
> In DB2, you can of course have cross-schema queries but no cross-db
> queries, unless you rig up the federated functionality to connect one
> db to the other.
A while ago I was at a client who wanted to migrate to DB2 and this
questions was raised during discussions with IBM. There was a way to do
this, if I remember correctly the solution involved creating views for
all tables from db2 that you wanted to use in db1 and maybe something
else. Can't tell you for sure, I'm not working with DB2.
Oracle, Sybase, Ms, Informix (? AFAIK) , mySql, they all support
cross-db queries.
Anyway, I thought it was important to bring this up. With large number
of apps and large amount of data having everything in one db is a sure
way for disaster, IMHO.
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
---------------------------(end of broadcast)---------------------------
gr...@turnstep.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> In fact I think postgresql is easier to use. Till date, I could never start
> mysql by hand and get it behave sanely. pg_ctl or nohup postmaster has always
> worked for me.
This is weird, because despite mysql's technical inferiority, it really is
pretty simple to use. Also seems a little hypocritical of you in light of
the RTFM rant later on in your email. :)
> Besides postgresql is true to it's resource usage. You allocate 128MB of
> shared buffers, and they are consumed. You stop postmaster and all the
> buffers are back to system. With mysql, I found that large amount of memory
> was never returned to system even after service shutdown. I hate black-boxes
> on my system where I can not fathom into. Had to reboot the machine.
"Black-boxes"? It's open-source, just like we are. Did you read their manual
"start to end"? Did you ask on their mailing lists? I'm no MySQL fan, but
I'd rather let them, not us, dish out the FUD. The original poster had some
valid points (auto-vacuum and non-intuitive commands) that still need
addressing, IMO.
- --
Greg Sabino Mullane gr...@turnstep.com
PGP Key: 0x14964AC8 200304160945
-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html
iD8DBQE+nV/EvJuQZxSWSsgRAsaXAKCAY3vGFxDzk9dniqojpi+RK3ToUwCgpv5L
Sl6e9Or440U5QeLIhvNsaro=
=k5Np
-----END PGP SIGNATURE-----
Shridhar Daithankar
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > In fact I think postgresql is easier to use. Till date, I could never
> > start mysql by hand and get it behave sanely. pg_ctl or nohup postmaster
> > has always worked for me.
>
> This is weird, because despite mysql's technical inferiority, it really is
> pretty simple to use. Also seems a little hypocritical of you in light of
> the RTFM rant later on in your email. :)
Yes. That is correct. But going thr. 3.5MB html to find out things which has
got tons of options and figuring out interdependencies by trial and error is
not a good job at that. Whoever thinks that such a style on manual writing is
good, needs an attitude readjustment. Postgresql manual is ten times better.
> > Besides postgresql is true to it's resource usage. You allocate 128MB of
> > shared buffers, and they are consumed. You stop postmaster and all the
> > buffers are back to system. With mysql, I found that large amount of
> > memory was never returned to system even after service shutdown. I hate
> > black-boxes on my system where I can not fathom into. Had to reboot the
> > machine.
>
> "Black-boxes"? It's open-source, just like we are. Did you read their
> manual "start to end"? Did you ask on their mailing lists? I'm no MySQL
> fan, but I'd rather let them, not us, dish out the FUD. The original poster
> had some valid points (auto-vacuum and non-intuitive commands) that still
> need addressing, IMO.
I didn't go to any mailing list. My point is, if I pierce the startup-shutdown
chapter in mysql manual and can not get it working by hand, either I am
stupid or something wrong with mysql. May sound arrogant but I count on
later.
Have you seen postgresql 101 I wrote? It is at
http://wiki.ael.be/index.php/PostgresQL101. It is that simple with
postgresql. Now this is not the forum but can anybody point me to similar
document for mysql. /etc/rc.d/init.d/mysql start always works but it does not
allow me to tweak options for mysqld which is first thing I want.
Anyway I must admit that I was reluctant to use mysql and was turned off
pretty quickly. Mine is probably a irreproducible bug but I did encounter it.
Shridhar
Hannu Krosing
> The original poster had some=20
> valid points (auto-vacuum and non-intuitive commands) that still need=20
> addressing, IMO.
As of 7.3 (or was it 7.2) auto-vacuum is just one line in crontab. In
many scenarios it can be left running continuously with very little
effect on performance. In others it must be run nightly, but having it
kick in at unexpected times may not be what you want at all. So it has
to be configured for good performance weather it is built-in or run in a
separate backend process.
And I can't see how "show tables" is more intuitive than "\dt" - I
expected it to be "list tables" or "tablelist" or "n=E4ita tabeleid" .
Once you have found \? it is all there (and you are advised to use \? at
psql startup).
That may also be why PostgreSQL is more popular in Japan - if one has to
remember nonsensical strings, then it is easier to remember short ones
;)
----------------
Sean Chittenden
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> > That's a pretty reasonable thought. I work for a shop that sells
> > Postgres support, and even we install MySQL for the Q&D ticket
> > tracking system we recommend because we can't justify the cost to
> > port it to postgres. If the postgres support were there, we would
> > surely be using it.
>
> > How to fix such a situation, I'm not sure. "MySQL Compatability
> > Mode," anyone? :-)
>
> What issues are creating a compatibility problem for you?
I don't think these should be hacked into the backend/libpq, but I
think it'd be a huge win to hack in "show *" support into psql for
MySQL users so they can type:
SHOW (databases|tables|views|functions|triggers|schemas);
I have yet to meet a MySQL user who understands the concept of system
catalogs even though it's just the 'mysql' database (this irritates me
enough as is)... gah, f- it: mysql users be damned, I have three
developers that think that postgresql is too hard to use because they
can't remember "\d [table name]" and I'm tired of hearing them bitch
when I push using PostgreSQL instead of MySQL. I have better things
to do with my time than convert their output to PostgreSQL. Here goes
nothing...
I've tainted psql and added a MySQL command compatibility layer for
the family of SHOW commands (psql [-m | --mysql]).
The attached patch does a few things:
1) Implements quite a number of SHOW commands (AGGREGATES, CASTS,
CATALOGS, COLUMNS, COMMENTS, CONSTRAINTS, CONVERSIONS, DATABASES,
DOMAINS, FUNCTIONS, HELP, INDEX, LARGEOBJECTS, NAMES, OPERATORS,
PRIVILEGES, PROCESSLIST, SCHEMAS, SEQUENCES, SESSION, STATUS,
TABLES, TRANSACTION, TYPES, USERS, VARIABLES, VIEWS)
SHOW thing
SHOW thing LIKE pattern
SHOW thing FROM pattern
SHOW HELP ON (topic || ALL);
etc.
Some of these don't have \ command eqiv's. :( I was tempted to add
them, but opted not to for now, but it'd certainly be a nice to
have.
2) Implements the necessary tab completion for the SHOW commands for
the tab happy newbies/folks out there. psql is more friendly than
mysql's CLI now in terms of tab completion for the show commands.
3) Few trailing whitespace characters were nuked
4) guc.c is now in sync with the list of available variables used for
tab completion
Few things to note:
1) SHOW INDEXES is the same as SHOW INDEX, I think MySQL is wrong in
this regard and that it should be INDEXES to be plural along with
the rest of the types, but INDEX is preserved for compatibility.
2) There are two bugs that I have yet to address
1) SHOW VARIABLES doesn't work, but "SHOW [TAB][TAB]y" does
2) "SHOW [variable_of_choice];" doesn't work, but "SHOW
[variable_of_choice]\n;" does work... not sure where this
problem is coming from
3) I think psql is more usable as a result of this more verbose
syntax, but it's not the prettiest thing on the planet (wrote a
small parser outside of the backend or libraries: I don't want to
get those dirty with MySQL's filth).
4) In an attempt to wean people over to PostgreSQL's syntax, I
included translation tips on how to use the psql equiv of the SHOW
commands. Going from SHOW foo to \d foo is easy, going from \d foo
to SHOW foo is hard and drives me nuts. This'll help userbase
retention of newbies/converts. :)
5) The MySQL mode is just a bounce layer that provides different
syntax wrapping exec_command() so it should provide little in the
way of maintenance headaches. Some of the SHOW commands, however,
don't have \ couterparts, but once they do and that code is
centralized, this feature should come for zero cost.
6) As an administrator, I'd be interested in having an environment
variable that I could set that'd turn on MySQL mode for some of my
bozo users that way they don't complain if they forget the -m
switch. Thoughts?
I'll try and iron out the last of those two bugs/features, but at this
point, would like to see this patch get wider testing/feedback.
Comments, as always, are welcome.
PostgreSQL_usability++
-sc
--
Sean Chittenden
--N/GrjenRD+RJfyz+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch
Index: command.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.95
diff -u -r1.95 command.c
--- command.c 2003/04/04 20:40:45 1.95
+++ command.c 2003/04/16 15:37:53
@@ -66,7 +66,386 @@
static bool do_connect(const char *new_dbname, const char *new_user);
static bool do_shell(const char *command);
+static char *eat_token(char *cp, char *token, size_t token_len);
+static char *eat_whitespace(char *cp);
+static size_t token_len(char *cp);
+
+#define _(x) gettext((x))
+
+/* These macros are a tad evil but saves a gagillion keystrokes and
+ * should only be used in HandleMySQLShowCmds(). */
+#define MYSQL_SHOW_PARSE_OPT_LIKE(cmd, cmd_len) do { \
+ cp = eat_whitespace(&tkn1[tkn1_len]); \
+ cp_pos = 0; \
+ if (cp == NULL) \
+ goto help; \
+ strncpy(my_line, cmd, cmd_len); \
+ tkn2 = eat_token(cp, "LIKE", 4); \
+ tkn2_len = token_len(tkn2); \
+ if (tkn2 != NULL) { \
+ sprintf(&my_line[cmd_len], " %.*s*", tkn2_len, tkn2); \
+ options_string = &my_line[cmd_len]; \
+ } \
+ if (!QUIET()) \
+ fprintf(stderr, "\n\tTIP: In %s, \"%s\" is natively written as \"\\%s%.*s%.*s%.*s\"\n\n", getprogname(), line, cmd, (tkn2_len ? 1 : 0), " ", tkn2_len, tkn2, (tkn2_len ? 1 : 0), "*"); \
+} while(0)
+
+#define MYSQL_SHOW_COPY_ARG(cmd, cmd_len) do { \
+ strncpy(my_line, cmd, cmd_len); \
+ if (!QUIET()) { \
+ fprintf(stderr, "\n\tTIP: In %s, \"%s\" is natively written as \"\\%s\"\n\n", getprogname(), line, cmd); \
+ } \
+} while(0)
+
/*----------
+ * HandleMySQLShowCmds:
+ *
+ * Handles all the different "SHOW" commands while in MySQL
+ * compatibility mode, ordinarily called by MainLoop().
+ *
+ * This function is a ripoff of HandleSlashCmds() and acts as a
+ * translation layer between the user input and exec_command().
+ *
+ * 'query_buf' contains the query-so-far, which may be modified by
+ * execution of the backslash command (for example, \r clears it)
+ * query_buf can be NULL if there is no query so far.
+ *
+ * Returns a status code indicating what action is desired, see command.h.
+ *----------
+ */
+
+backslashResult
+HandleMySQLShowCmds(const char *line,
+ PQExpBuffer query_buf,
+ const char **end_of_cmd,
+ volatile int *paren_level)
+{
+ backslashResult status = CMD_SKIP_LINE;
+ bool run_cmd;
+ char *cp, *my_line, *tkn1, *tkn2;
+ char *options_string = NULL;
+ size_t cp_pos, tkn1_len, tkn2_len;
+ const char *continue_parse = NULL; /* tell the mainloop where the
+ * backslash command ended */
+
+#ifdef USE_ASSERT_CHECKING
+ assert(line);
+#endif
+
+ my_line = xstrdup(line);
+ run_cmd = true;
+ cp_pos = strlen(line);
+ continue_parse = &line[cp_pos];
+ if (end_of_cmd != NULL)
+ *end_of_cmd = &line[cp_pos];
+
+ /*
+ * Find the thing that we're showing
+ */
+ cp = tkn1 = eat_token(my_line, "SHOW", 4);
+ tkn1_len = token_len(tkn1);
+ if (cp == NULL) {
+ status = CMD_UNKNOWN;
+ goto error;
+ }
+
+ if (cp[0] == '\0') {
+ help:
+ MYSQL_SHOW_COPY_ARG("?", 2);
+ } else if (strncasecmp(tkn1, "AGGREGATES", tkn1_len) == 0) {
+ /* SHOW AGGREGATES [LIKE pattern] */
+ /* \da [PATTERN] list aggregate functions */
+ MYSQL_SHOW_PARSE_OPT_LIKE("da", 3);
+ } else if (strncasecmp(tkn1, "CASTS", tkn1_len) == 0) {
+ /* SHOW CASTS */
+ /* \dC list casts */
+ MYSQL_SHOW_COPY_ARG("dC", 3);
+ } else if (strncasecmp(tkn1, "CATALOGS", tkn1_len) == 0) {
+ /* SHOW CATALOGS [LIKE pattern] */
+ /* \dS lists system catalogs */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dS", 3);
+ } else if (strncasecmp(tkn1, "COLUMNS", tkn1_len) == 0) {
+ /* SHOW COLUMNS FROM tbl_name */
+ /* \dt [PATTERN] list columns in a table */
+ cp = eat_whitespace(&tkn1[tkn1_len]);
+ cp_pos = 0;
+ if (cp == NULL)
+ goto help;
+
+ /* Skip past the token word FROM and return the next token */
+ cp = tkn2 = eat_token(cp, "FROM", 4);
+ tkn2_len = token_len(tkn2);
+ if (tkn2 == NULL || tkn2[0] == '\0')
+ goto help;
+
+ /* Abuse my_line since my_line is always shorter than the string passed in */
+ strncpy(my_line, "d", 2);
+ sprintf(&my_line[2], "%.*s", tkn2_len, tkn2);
+ options_string = &my_line[2];
+ if (!QUIET())
+ fprintf(stderr, "\n\tTIP: In %s, \"%s\" is natively written as \"\\%s%.*s%.*s\"\n\n", getprogname(), line, "d", (tkn2_len ? 1 : 0), " ", tkn2_len, tkn2);
+ } else if (strncasecmp(tkn1, "COMMENTS", tkn1_len) == 0) {
+ /* SHOW COMMENTS [LIKE pattern] */
+ /* \dd [PATTERN] show comment for object */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dd", 3);
+ } else if (strncasecmp(tkn1, "CONVERSIONS", tkn1_len) == 0) {
+ /* SHOW CONVERSIONS [LIKE pattern] */
+ /* \dc [PATTERN] list conversions */
+ MYSQL_SHOW_COPY_ARG("dc", 3);
+ } else if (strncasecmp(tkn1, "DATABASES", tkn1_len) == 0) {
+ /* \l list all databases */
+ MYSQL_SHOW_COPY_ARG("l", 2);
+ } else if (strncasecmp(tkn1, "DOMAINS", tkn1_len) == 0) {
+ /* SHOW DOMAINS [LIKE pattern] */
+ /* \dD [PATTERN] list domains */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dD", 3);
+ } else if (strncasecmp(tkn1, "FUNCTIONS", tkn1_len) == 0) {
+ /* SHOW FUNCTIONS [LIKE pattern] */
+ /* \df [PATTERN] list functions */
+ MYSQL_SHOW_PARSE_OPT_LIKE("df", 3);
+ } else if (strncasecmp(tkn1, "HELP", tkn1_len) == 0) {
+ /* SHOW HELP [ON (function_name|ALL) ]*/
+ /* \h [NAME] help on syntax of SQL commands, * for all commands */
+ strncpy(my_line, "h", 2);
+ cp = eat_whitespace(&tkn1[tkn1_len]);
+ cp_pos = 0;
+ if (cp == NULL)
+ goto help;
+
+ /* Skip past the token word FROM and return the next token */
+ cp = tkn2 = eat_token(cp, "ON", 2);
+ tkn2_len = token_len(tkn2);
+ if (tkn2 == NULL || tkn2[0] == '\0') {
+ strncpy(my_line, "h", 2);
+ } else {
+ strncpy(my_line, "h", 2);
+ if (strncasecmp(tkn2, "ALL", 3) == 0) {
+ strncpy(&my_line[2], " *", 3);
+ tkn2 = &my_line[3];
+ } else
+ sprintf(&my_line[2], " %.*s", tkn2_len, tkn2);
+
+ options_string = &my_line[3];
+ }
+ if (!QUIET())
+ fprintf(stderr, "\n\tTIP: In %s, \"%s\" is natively written as \"\\%s%.*s%.*s\"\n\n", getprogname(), line, "h", (tkn2_len ? 1 : 0), " ", tkn2_len, tkn2);
+ } else if (strncasecmp(tkn1, "INDEXES", tkn1_len) == 0 ||
+ strncasecmp(tkn1, "INDEX", tkn1_len) == 0) {
+ /* SHOW INDEX (FROM table_name|LIKE pattern) */
+ /* FROM = query with arg comparing to table names. LIKE = query with arg comparing to index names */
+ PQExpBufferData buf;
+ PGresult *res;
+ printQueryOpt myopt = pset.popt;
+
+ cp = eat_whitespace(&tkn1[tkn1_len]);
+ cp_pos = 0;
+ if (cp == NULL)
+ goto help;
+
+ if (strncasecmp(cp, "FROM", 4) == 0) {
+ cp = tkn2 = eat_token(cp, "FROM", 4);
+
+ tkn2_len = token_len(tkn2);
+ if (tkn2 == NULL || tkn2[0] == '\0')
+ goto help;
+
+ initPQExpBuffer(&buf);
+ /* Ned to populate the buffer */
+ printfPQExpBuffer(&buf,
+ "SELECT n.nspname AS \"Schema\", c2.relname AS \"Table\", c.relname AS \"Name\",\n"
+ " u.usename AS \"Owner\", i.indisclustered AS \"Clustered\", i.indisunique AS \"Unique\",\n"
+ " i.indisprimary AS \"Primary\"\n"
+ " FROM pg_catalog.pg_class c\n"
+ " JOIN pg_catalog.pg_index i ON i.indexrelid = c.oid\n"
+ " JOIN pg_catalog.pg_class c2 ON i.indrelid = c2.oid\n"
+ " LEFT JOIN pg_catalog.pg_user u ON u.usesysid= c.relowner\n"
+ " LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace\n"
+ " WHERE c.relkind IN ('i','') AND pg_catalog.pg_table_is_visible(c.oid)\n"
+ " AND c2.relname ~ '^%.*s' ORDER BY c2.relname, c.relname",
+ tkn2_len, tkn2);
+
+ } else if (strncasecmp(cp, "LIKE", 4) == 0) {
+ cp = tkn2 = eat_token(cp, "LIKE", 4);
+
+ tkn2_len = token_len(tkn2);
+ if (tkn2 == NULL || tkn2[0] == '\0')
+ goto help;
+
+ initPQExpBuffer(&buf);
+
+ /* Ned to populate the buffer */
+ printfPQExpBuffer(&buf,
+ "SELECT n.nspname AS \"Schema\", c2.relname AS \"Table\", c.relname AS \"Name\",\n"
+ " u.usename AS \"Owner\", i.indisclustered AS \"Clustered\", i.indisunique AS \"Unique\",\n"
+ " i.indisprimary AS \"Primary\"\n"
+ " FROM pg_catalog.pg_class c\n"
+ " JOIN pg_catalog.pg_index i ON i.indexrelid = c.oid\n"
+ " JOIN pg_catalog.pg_class c2 ON i.indrelid = c2.oid\n"
+ " LEFT JOIN pg_catalog.pg_user u ON u.usesysid= c.relowner\n"
+ " LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace\n"
+ " WHERE c.relkind IN ('i','') AND pg_catalog.pg_table_is_visible(c.oid)\n"
+ " AND c.relname ~ '^%.*s' ORDER BY c.relname",
+ tkn2_len, tkn2);
+ } else
+ goto help;
+
+ res = PSQLexec(buf.data, false);
+ termPQExpBuffer(&buf);
+ if (!res)
+ goto error;
+
+ if (PQntuples(res) == 0 && !QUIET())
+ fprintf(pset.queryFout, _("No matching indexes found.\n"));
+ else
+ {
+ myopt.nullPrint = NULL;
+ myopt.title = _("List of indexes");
+
+ printQuery(res, &myopt, pset.queryFout);
+ }
+
+ PQclear(res);
+ run_cmd = false;
+ options_string = &my_line[2];
+ } else if (strncasecmp(tkn1, "LARGEOBJECTS", tkn1_len) == 0) {
+ /* SHOW LARGEOBJECTS */
+ /* \dl list large objects */
+ MYSQL_SHOW_COPY_ARG("dl", 3);
+ } else if (strncasecmp(tkn1, "OPERATORS", tkn1_len) == 0) {
+ /* SHOW OPERATORS [LIKE name] */
+ /* \do [NAME] list operators */
+ MYSQL_SHOW_PARSE_OPT_LIKE("do", 3);
+ } else if (strncasecmp(tkn1, "PRIVILEGES", tkn1_len) == 0) {
+ /* SHOW PRIVILEGES (ON name|LIKE pattern) */
+ /* \dp [PATTERN] list table access privileges */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dp", 3);
+ } else if (strncasecmp(tkn1, "PROCESSLIST", tkn1_len) == 0) {
+ /* SHOW PROCESSLIST */
+ /* SELECT * FROM pg_catalog.pg_stat_activity ; */
+ PQExpBufferData buf;
+ PGresult *res;
+ printQueryOpt myopt = pset.popt;
+
+ initPQExpBuffer(&buf);
+ printfPQExpBuffer(&buf,
+ "SELECT a.datname AS \"Database\", a.procpid AS \"PID\", a.usename AS \"Username\",\n"
+ " a.current_query AS \"Current Query\" FROM pg_catalog.pg_stat_activity a");
+
+ res = PSQLexec(buf.data, false);
+ termPQExpBuffer(&buf);
+ if (!res)
+ goto error;
+
+ if (PQntuples(res) == 0 && !QUIET())
+ fprintf(pset.queryFout, _("No stats available.\n"));
+ else
+ {
+ myopt.nullPrint = NULL;
+ myopt.title = _("List of processes");
+
+ printQuery(res, &myopt, pset.queryFout);
+ }
+
+ PQclear(res);
+ run_cmd = false;
+ options_string = &my_line[2];
+ } else if (strncasecmp(tkn1, "SCHEMAS", tkn1_len) == 0) {
+ /* SHOW SCHEMAS [LIKE pattern] */
+ /* \dn [PATTERN] list schemas */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dn", 3);
+ } else if (strncasecmp(tkn1, "SEQUENCES", tkn1_len) == 0) {
+ /* SHOW SEQUENCES [LIKE pattern] */
+ /* ds [PATTERN] list sequences */
+ MYSQL_SHOW_PARSE_OPT_LIKE("ds", 3);
+ } else if (strncasecmp(tkn1, "STATUS", tkn1_len) == 0) {
+ /* SHOW STATUS */
+ /* SELECT * FROM pg_catalog.pg_stat_database ; */
+ PQExpBufferData buf;
+ PGresult *res;
+ printQueryOpt myopt = pset.popt;
+
+ initPQExpBuffer(&buf);
+ printfPQExpBuffer(&buf,
+ "SELECT d.datname AS \"Database\", d.numbackends AS \"Num Backends\",\n"
+ " d.xact_commit AS \"Txn Commit\", d.xact_rollback AS \"Txn Rollback\",\n"
+ " d.blks_read AS \"Blocks Read\", d.blks_hit AS \"Blocks Hit\"\n"
+ " FROM pg_catalog.pg_stat_database d");
+
+ res = PSQLexec(buf.data, false);
+ termPQExpBuffer(&buf);
+ if (!res)
+ goto error;
+
+ if (PQntuples(res) == 0 && !QUIET())
+ fprintf(pset.queryFout, _("No status available.\n"));
+ else
+ {
+ myopt.nullPrint = NULL;
+ myopt.title = _("Status");
+
+ printQuery(res, &myopt, pset.queryFout);
+ }
+
+ PQclear(res);
+ run_cmd = false;
+ options_string = &my_line[2];
+ } else if (strncasecmp(tkn1, "TABLES", tkn1_len) == 0) {
+ /* SHOW TABLES [LIKE pattern] */
+ /* \dt [PATTERN] list tables */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dt", 3);
+ } else if (strncasecmp(tkn1, "TYPES", tkn1_len) == 0) {
+ /* SHOW TYPES [LIKE pattern] */
+ /* \dT [PATTERN] list data types */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dT", 3);
+ } else if (strncasecmp(tkn1, "USERS", tkn1_len) == 0) {
+ /* SHOW USERS [LIKE pattern] */
+ /* \du [PATTERN] list users */
+ MYSQL_SHOW_PARSE_OPT_LIKE("du", 3);
+ } else if (strncasecmp(tkn1, "VARIABLES", tkn1_len) == 0) {
+ /* INCOMPLETE - XXXXXXXXXXXXXXXXXX
+ * Pushing "SHOW [TAB][TAB]y" however, does work */
+ /* SHOW VARIABLES */
+ /* Need to iterate through the list of variables that would
+ * normally be shown via "SHOW [TAB][TAB]" when not in mysql
+ * compatibility mode. This mode will be an oddity in that
+ * it won't return normal results and will look a tad funky,
+ * I think. This could iterate through the list of
+ * variables stored in *pgsql_variables[] and show their
+ * values. */
+ MYSQL_SHOW_COPY_ARG("?", 2);
+ } else if (strncasecmp(tkn1, "VIEWS", tkn1_len) == 0) {
+ /* SHOW VIEWS [LIKE pattern] */
+ /* \dv [PATTERN list views */
+ MYSQL_SHOW_PARSE_OPT_LIKE("dv", 3);
+ } else {
+ /* SHOW [variable_name] */
+ /* This is syntatically the same the normal SHOW syntax
+ * without MySQL compatibility mode turned on. */
+ /* BUG XXXXXXXXXXXXXX This currently works, but in an odd
+ * manner, and why, I'm not sure.
+ *
+ * "SHOW TimeZone;" Doesn't work, but
+ * "SHOW TimeZone\n;" Does work.
+ */
+ strncpy(my_line, "SHOW", 5);
+ tkn2 = eat_whitespace(&tkn1[tkn1_len]);
+ tkn2_len = token_len(tkn2);
+ strncpy(&my_line[6], tkn2, tkn2_len);
+ options_string = tkn2;
+ }
+
+ if (run_cmd == true)
+ status = exec_command(my_line, options_string, &continue_parse, query_buf, paren_level);
+
+ error:
+ free(my_line);
+ query_buf->len = 0;
+
+ return status;
+}
+
+
+/*----------
* HandleSlashCmds:
*
* Handles all the different commands that start with '\',
@@ -1726,6 +2105,48 @@
break;
}
return "unknown";
+}
+
+
+static char *eat_token(char *cp, char *token, size_t token_len) {
+ size_t cp_pos;
+ char *p;
+
+ p = cp;
+ /* Skip past the token */
+ cp_pos = strncasecmp(p, token, token_len);
+ if (cp_pos != 0)
+ return(NULL);
+
+ /* Skip past the spaces after the token */
+ p = eat_whitespace(&p[token_len]);
+ return(p);
+}
+
+static char *eat_whitespace(char *cp) {
+ size_t cp_pos;
+
+ if (cp == NULL)
+ return(NULL);
+
+ for (cp_pos = 0; cp[cp_pos] != NULL; cp_pos++)
+ if (!isspace(cp[cp_pos]))
+ break;
+
+ return(&cp[cp_pos]);
+}
+
+static size_t token_len(char *cp) {
+ size_t cp_pos;
+
+ if (cp == NULL)
+ return((size_t)0);
+
+ for (cp_pos = 0; cp[cp_pos] != NULL; cp_pos++)
+ if (isspace(cp[cp_pos]))
+ break;
+
+ return(cp_pos);
}
Index: command.h
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.h,v
retrieving revision 1.14
diff -u -r1.14 command.h
--- command.h 2002/03/27 19:16:13 1.14
+++ command.h 2003/04/16 15:37:53
@@ -26,6 +26,11 @@
} backslashResult;
+backslashResult HandleMySQLShowCmds(const char *line,
+ PQExpBuffer query_buf,
+ const char **end_of_cmd,
+ volatile int *paren_level);
+
backslashResult HandleSlashCmds(const char *line,
PQExpBuffer query_buf,
const char **end_of_cmd,
Index: help.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/help.c,v
retrieving revision 1.72
diff -u -r1.72 help.c
--- help.c 2003/04/14 16:23:36 1.72
+++ help.c 2003/04/16 15:37:54
@@ -97,6 +97,7 @@
puts(_(" -v NAME=VALUE set psql variable 'NAME' to 'VALUE'"));
puts(_(" -X do not read startup file (~/.psqlrc)"));
puts(_(" --help show this help, then exit"));
+ puts(_(" --mysql, -m Run in quasi-MySQL compatibility mode"));
puts(_(" --version output version information, then exit"));
puts(_("\nInput and output options:"));
Index: mainloop.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/mainloop.c,v
retrieving revision 1.55
diff -u -r1.55 mainloop.c
--- mainloop.c 2003/03/21 03:28:29 1.55
+++ mainloop.c 2003/04/16 15:37:54
@@ -274,7 +274,7 @@
else if (line[i] == '/' && line[i + thislen] == '*')
{
in_xcomment++;
- if (in_xcomment == 1)
+ if (in_xcomment == 1)
ADVANCE_1;
}
@@ -404,11 +404,12 @@
}
/* backslash command */
- else if (bslash_count)
+ else if (bslash_count || (pset.mode_mysql == true && i > 0 && strncasecmp(&line[i - 1], "SHOW", 4) == 0))
{
const char *end_of_cmd = NULL;
- line[i - prevlen] = '\0'; /* overwrites backslash */
+ if (bslash_count)
+ line[i - prevlen] = '\0'; /* overwrites backslash */
/* is there anything else on the line for the command? */
if (line[query_start + strspn(line + query_start, " \t\n\r")] != '\0')
@@ -423,9 +424,15 @@
appendPQExpBufferStr(query_buf, line + query_start);
}
- /* handle backslash command */
- slashCmdStatus = HandleSlashCmds(&line[i],
- query_buf->len > 0 ? query_buf : previous_buf,
+ /* Handle backslash command/MySQL compatibility */
+ if (pset.mode_mysql == true && strncasecmp(&line[i - 1], "SHOW", 4) == 0)
+ slashCmdStatus = HandleMySQLShowCmds(&line[i - 1],
+ query_buf->len > 0 ? query_buf : previous_buf,
+ &end_of_cmd,
+ &paren_level);
+ else
+ slashCmdStatus = HandleSlashCmds(&line[i],
+ query_buf->len > 0 ? query_buf : previous_buf,
&end_of_cmd,
&paren_level);
Index: settings.h
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/settings.h,v
retrieving revision 1.13
diff -u -r1.13 settings.h
--- settings.h 2002/03/05 00:01:02 1.13
+++ settings.h 2003/04/16 15:37:54
@@ -51,6 +51,7 @@
bool issuper; /* is the current user a superuser? (used
* to form the prompt) */
bool timing; /* timing of all queries */
+ bool mode_mysql; /* MySQL command compatibility (show commands) */
} PsqlSettings;
extern PsqlSettings pset;
Index: startup.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.73
diff -u -r1.73 startup.c
--- startup.c 2003/04/04 20:42:13 1.73
+++ startup.c 2003/04/16 15:37:54
@@ -128,6 +128,7 @@
pset.cur_cmd_source = stdin;
pset.cur_cmd_interactive = false;
+ pset.mode_mysql = false;
pset.encoding = PQenv2encoding();
pset.vars = CreateVariableSpace();
@@ -330,6 +331,7 @@
{"host", required_argument, NULL, 'h'},
{"html", no_argument, NULL, 'H'},
{"list", no_argument, NULL, 'l'},
+ {"mysql", no_argument, NULL, 'm'},
{"no-readline", no_argument, NULL, 'n'},
{"output", required_argument, NULL, 'o'},
{"port", required_argument, NULL, 'p'},
@@ -359,7 +361,7 @@
memset(options, 0, sizeof *options);
- while ((c = getopt_long(argc, argv, "aAc:d:eEf:F:h:Hlno:p:P:qR:sStT:uU:v:VWxX?",
+ while ((c = getopt_long(argc, argv, "aAc:d:eEf:F:h:Hlmno:p:P:qR:sStT:uU:v:VWxX?",
long_options, &optindex)) != -1)
{
switch (c)
@@ -404,6 +406,9 @@
break;
case 'l':
options->action = ACT_LIST_DB;
+ break;
+ case 'm':
+ pset.mode_mysql = true;
break;
case 'n':
options->no_readline = true;
Index: tab-complete.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.76
diff -u -r1.76 tab-complete.c
--- tab-complete.c 2003/04/03 20:18:16 1.76
+++ tab-complete.c 2003/04/16 15:37:55
@@ -85,8 +85,11 @@
static char *complete_from_list(const char *text, int state);
static PGresult *exec_query(char *query);
+static bool find_word_in_list(char **word_list, int *valid_indexes, char *word);
char *quote_file_name(char *text, int match_type, char *quote_pointer);
+static char **merge_lists(char **list1, char **list2);
+
/*static char * dequote_file_name(char *text, char quote_char);*/
static char *previous_word(int point, int skip);
@@ -435,7 +438,178 @@
{NULL, NO_SCHEMA, NULL} /* end of list */
};
+char *sql_commands[] = {
+ "ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER", "COMMENT",
+ "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE", "DELETE", "DROP", "EXECUTE",
+ "EXPLAIN", "FETCH", "GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY",
+ "PREPARE", "REINDEX", "RESET", "REVOKE", "ROLLBACK", "SELECT", "SET", "SHOW",
+ "TRUNCATE", "UNLISTEN", "UPDATE", "VACUUM", NULL
+};
+
+char **mysql_mode_show_merged = NULL;
+
+char *mysql_mode_show_words[] = {
+ "AGGREGATES", "CASTS", "CATALOGS", "COLUMNS", "COMMENTS", "CONVERSIONS", "DATABASES",
+ "DOMAINS", "FUNCTIONS", "HELP", "INDEXES", "LARGEOBJECTS", "OPERATORS", "PRIVILEGES",
+ "PROCESSLIST", "SCHEMAS", "SEQUENCES", "STATUS", "TABLES", "TYPES", "USERS",
+ "VARIABLES", "VIEWS", NULL
+};
+
+int mysql_mode_show_valid_like_commands[] = {
+ 0, 2, 4, 5, 7, 8, 10, 12, 13, 15, 16, 18, 19, 20, 22, -1
+};
+char *mysql_mode_show_select_origin_words[] = {
+ "FROM", "LIKE", NULL
+};
+
+int mysql_mode_show_valid_from_like[] = {
+ 10, -1
+};
+
+char *pgsql_variables[] = {
+ /* these SET arguments are known in gram.y */
+ "CONSTRAINTS",
+ "NAMES",
+ "SESSION",
+ "TRANSACTION",
+
+ /*
+ * the rest should match USERSET and possibly SUSET entries in
+ * backend/utils/misc/guc.c.
+ */
+ "australian_timezones",
+ "authentication_timeout",
+ "autocommit",
+ "checkpoint_segments",
+ "checkpoint_timeout",
+ "checkpoint_warning",
+ "client_encoding",
+ "client_min_messages",
+ "commit_delay",
+ "commit_siblings",
+ "cpu_index_tuple_cost",
+ "cpu_operator_cost",
+ "cpu_tuple_cost",
+ "DateStyle",
+ "db_user_namespace",
+ "deadlock_timeout",
+#ifdef USE_ASSERT_CHECKING
+ "debug_assertions",
+#endif
+ "debug_pretty_print",
+ "debug_print_parse",
+ "debug_print_plan",
+ "debug_print_rewritten",
+#ifdef LOCK_DEBUG
+ "debug_deadlocks",
+#endif
+ "default_statistics_target",
+ "default_transaction_isolation",
+ "default_transaction_read_only",
+ "dynamic_library_path",
+ "effective_cache_size",
+ "enable_hashagg",
+ "enable_hashjoin",
+ "enable_indexscan",
+ "enable_mergejoin",
+ "enable_nestloop",
+ "enable_seqscan",
+ "enable_sort",
+ "enable_tidscan",
+ "explain_pretty_print",
+ "extra_float_digits",
+ "from_collapse_limit",
+ "fsync",
+ "geqo",
+ "geqo_effort",
+ "geqo_generations",
+ "geqo_pool_size",
+ "geqo_random_seed",
+ "geqo_selection_bias",
+ "geqo_threshold",
+ "join_collapse_limit",
+ "krb_server_keyfile",
+ "lc_messages",
+ "lc_monetary",
+ "lc_numeric",
+ "lc_time",
+#ifdef BTREE_BUILD_STATS
+ "log_btree_build_stats",
+#endif
+ "log_connections",
+ "log_duration",
+ "log_executor_stats",
+ "log_hostname",
+ "log_min_error_statement",
+ "log_min_messages",
+ "log_parser_stats",
+ "log_pid",
+ "log_planner_stats",
+ "log_source_port",
+ "log_statement",
+ "log_statement_stats",
+ "log_timestamp",
+ "max_connections",
+ "max_expr_depth",
+ "max_files_per_process",
+ "max_fsm_pages",
+ "max_fsm_relations",
+ "max_locks_per_transaction",
+ "password_encryption",
+ "pre_auth_delay",
+ "preload_libraries",
+ "port",
+ "random_page_cost",
+ "regex_flavor",
+ "search_path",
+ "server_encoding",
+ "silent_mode",
+ "shared_buffers",
+ "seed",
+ "server_encoding",
+ "session_authorization",
+ "shared_buffers",
+ "sort_mem",
+ "sql_inheritance",
+ "ssl",
+ "statement_timeout",
+ "stats_block_level",
+ "stats_command_string",
+ "stats_reset_on_server_start",
+ "stats_row_level",
+ "stats_start_collector",
+ "superuser_reserved_connections",
+#ifdef HAVE_SYSLOG
+ "syslog",
+ "syslog_facility",
+ "syslog_ident",
+#endif
+ "tcpip_socket",
+ "TimeZone",
+ "trace_notify",
+#ifdef LOCK_DEBUG
+ "trace_lock_oidmin",
+ "trace_lock_table",
+ "trace_locks",
+ "trace_lwlocks",
+ "trace_userlocks",
+#endif
+ "transaction_isolation",
+ "transaction_read_only",
+ "transform_null_equals",
+ "unix_socket_directory",
+ "unix_socket_group",
+ "unix_socket_permissions",
+ "vacuum_mem",
+ "virtual_host",
+ "wal_buffers",
+ "wal_debug",
+ "wal_sync_method",
+ "zero_damaged_pages",
+ NULL
+};
+
/* A couple of macros to ease typing. You can use these to complete the given
string with
1) The results from a query you pass it. (Perhaps one of those above?)
@@ -473,123 +647,10 @@
*prev3_wd,
*prev4_wd;
- static char *sql_commands[] = {
- "ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER", "COMMENT",
- "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE", "DELETE", "DROP", "EXECUTE",
- "EXPLAIN", "FETCH", "GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY",
- "PREPARE", "REINDEX", "RESET", "REVOKE", "ROLLBACK", "SELECT", "SET", "SHOW",
- "TRUNCATE", "UNLISTEN", "UPDATE", "VACUUM", NULL
- };
-
- static char *pgsql_variables[] = {
- /* these SET arguments are known in gram.y */
- "CONSTRAINTS",
- "NAMES",
- "SESSION",
- "TRANSACTION",
-
- /*
- * the rest should match USERSET and possibly SUSET entries in
- * backend/utils/misc/guc.c.
- */
- "australian_timezones",
- "autocommit",
- "client_encoding",
- "client_min_messages",
- "commit_delay",
- "commit_siblings",
- "cpu_index_tuple_cost",
- "cpu_operator_cost",
- "cpu_tuple_cost",
- "DateStyle",
- "deadlock_timeout",
- "debug_pretty_print",
- "debug_print_parse",
- "debug_print_plan",
- "debug_print_rewritten",
- "default_statistics_target",
- "default_transaction_isolation",
- "default_transaction_read_only",
- "dynamic_library_path",
- "effective_cache_size",
- "enable_hashagg",
- "enable_hashjoin",
- "enable_indexscan",
- "enable_mergejoin",
- "enable_nestloop",
- "enable_seqscan",
- "enable_sort",
- "enable_tidscan",
- "explain_pretty_print",
- "extra_float_digits",
- "from_collapse_limit",
- "fsync",
- "geqo",
- "geqo_effort",
- "geqo_generations",
- "geqo_pool_size",
- "geqo_random_seed",
- "geqo_selection_bias",
- "geqo_threshold",
- "join_collapse_limit",
- "krb_server_keyfile",
- "lc_messages",
- "lc_monetary",
- "lc_numeric",
- "lc_time",
- "log_duration",
- "log_executor_stats",
- "log_min_error_statement",
- "log_min_messages",
- "log_parser_stats",
- "log_planner_stats",
- "log_statement",
- "log_statement_stats",
- "max_connections",
- "max_expr_depth",
- "max_files_per_process",
- "max_fsm_pages",
- "max_fsm_relations",
- "max_locks_per_transaction",
- "password_encryption",
- "port",
- "random_page_cost",
- "regex_flavor",
- "search_path",
- "shared_buffers",
- "seed",
- "server_encoding",
- "sort_mem",
- "sql_inheritance",
- "ssl",
- "statement_timeout",
- "stats_block_level",
- "stats_command_string",
- "stats_reset_on_server_start",
- "stats_row_level",
- "stats_start_collector",
- "superuser_reserved_connections",
- "syslog",
- "syslog_facility",
- "syslog_ident",
- "tcpip_socket",
- "TimeZone",
- "trace_notify",
- "transform_null_equals",
- "unix_socket_directory",
- "unix_socket_group",
- "unix_socket_permissions",
- "vacuum_mem",
- "wal_buffers",
- "wal_debug",
- "wal_sync_method",
- NULL
- };
-
static char *backslash_commands[] = {
- "\\a", "\\connect", "\\C", "\\cd", "\\copy", "\\copyright",
+ "\\a", "\\connect", "\\C", "\\cd", "\\copy", "\\copyright",
"\\d", "\\da", "\\dc", "\\dC", "\\dd", "\\dD", "\\df", "\\di",
- "\\dl", "\\dn", "\\do", "\\dp", "\\ds", "\\dS", "\\dt", "\\dT",
+ "\\dl", "\\dn", "\\do", "\\dp", "\\ds", "\\dS", "\\dt", "\\dT",
"\\dv", "\\du",
"\\e", "\\echo", "\\encoding",
"\\f", "\\g", "\\h", "\\help", "\\H", "\\i", "\\l",
@@ -630,13 +691,13 @@
/* CREATE or DROP but not ALTER TABLE sth DROP */
/* complete with something you can create or drop */
- else if (strcasecmp(prev_wd, "CREATE") == 0 ||
+ else if (strcasecmp(prev_wd, "CREATE") == 0 ||
(strcasecmp(prev_wd, "DROP") == 0 &&
strcasecmp(prev3_wd,"TABLE") != 0 ))
matches = completion_matches(text, create_command_generator);
/* ALTER */
- /* complete with what you can alter (TABLE, GROUP, USER, ...)
+ /* complete with what you can alter (TABLE, GROUP, USER, ...)
* unless we're in ALTER TABLE sth ALTER*/
else if (strcasecmp(prev_wd, "ALTER") == 0 &&
strcasecmp(prev3_wd, "TABLE") != 0 )
@@ -695,7 +756,7 @@
}
/* If we have TABLE <sth> DROP COLUMN, provide list of columns */
else if (strcasecmp(prev4_wd, "TABLE") == 0 &&
- strcasecmp(prev2_wd, "DROP") == 0 &&
+ strcasecmp(prev2_wd, "DROP") == 0 &&
strcasecmp(prev_wd, "COLUMN") == 0)
COMPLETE_WITH_ATTR(prev3_wd);
@@ -983,7 +1044,7 @@
"SELECT 'SCHEMA' AS relname ");
/* Complete "GRANT/REVOKE * ON * " with "TO" */
- else if ((strcasecmp(prev4_wd, "GRANT") == 0 ||
+ else if ((strcasecmp(prev4_wd, "GRANT") == 0 ||
strcasecmp(prev4_wd, "REVOKE") == 0) &&
strcasecmp(prev2_wd, "ON") == 0)
{
@@ -1102,6 +1163,42 @@
/* SET, RESET, SHOW */
/* Complete with a variable name */
+ else if (pset.mode_mysql == true &&
+ (strcasecmp(prev3_wd, "SHOW") == 0 &&
+ find_word_in_list(mysql_mode_show_words, mysql_mode_show_valid_like_commands, prev2_wd) == true &&
+ strncasecmp(prev_wd, "LIKE", 4) == 0))
+ {
+ if (strncasecmp(prev2_wd, "INDEX", 5) == 0)
+ COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_indexes);
+ else
+ COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_tables);
+ }
+ else if (pset.mode_mysql == true && (strcasecmp(prev2_wd, "SHOW") == 0 &&
+ find_word_in_list(mysql_mode_show_words, mysql_mode_show_valid_from_like, prev_wd) == true))
+ COMPLETE_WITH_LIST(mysql_mode_show_select_origin_words);
+ else if (pset.mode_mysql == true && (strcasecmp(prev2_wd, "SHOW") == 0 &&
+ find_word_in_list(mysql_mode_show_words, mysql_mode_show_valid_like_commands, prev_wd) == true))
+ COMPLETE_WITH_CONST("LIKE");
+ else if (pset.mode_mysql == true && (strcasecmp(prev2_wd, "SHOW") == 0 &&
+ strcasecmp(prev_wd, "COLUMNS") == 0))
+ COMPLETE_WITH_CONST("FROM");
+ else if (pset.mode_mysql == true && (strcasecmp(prev2_wd, "SHOW") == 0 &&
+ strcasecmp(prev_wd, "HELP") == 0))
+ COMPLETE_WITH_CONST("ON");
+ else if (pset.mode_mysql == true && (strcasecmp(prev3_wd, "SHOW") == 0 &&
+ strcasecmp(prev2_wd, "HELP") == 0 &&
+ strcasecmp(prev_wd, "ON") == 0))
+ COMPLETE_WITH_LIST(sql_commands);
+ else if (pset.mode_mysql == true && strcasecmp(prev_wd, "SHOW") == 0)
+ {
+ if (mysql_mode_show_merged == NULL)
+ mysql_mode_show_merged = merge_lists(mysql_mode_show_words, pgsql_variables);
+
+ if (mysql_mode_show_merged != NULL)
+ COMPLETE_WITH_LIST(mysql_mode_show_merged);
+ else
+ COMPLETE_WITH_LIST(mysql_mode_show_words);
+ }
else if ((strcasecmp(prev_wd, "SET") == 0 &&
strcasecmp(prev3_wd, "UPDATE") != 0) ||
strcasecmp(prev_wd, "RESET") == 0 ||
@@ -1399,9 +1496,9 @@
/* This creates a list of matching things, according to a query pointed to
by completion_charp.
The query can be one of two kinds:
- - A simple query which must contain a %d and a %s, which will be replaced
+ - A simple query which must contain a %d and a %s, which will be replaced
by the string length of the text and the text itself. The query may also
- have another %s in it, which will be replaced by the value of
+ have another %s in it, which will be replaced by the value of
completion_info_charp.
or:
- A schema query used for completion of both schema and relation names;
@@ -1658,6 +1755,46 @@
return s;
}
+
+
+static bool
+find_word_in_list(char **word_list, int *valid_indexes, char *word)
+{
+ size_t i;
+
+ for (i = 0; valid_indexes[i] != -1; i++)
+ if (strcasecmp(word_list[valid_indexes[i]], word) == 0)
+ return(true);
+
+ return(false);
+}
+
+static char **
+merge_lists(char **list1, char **list2)
+{
+ size_t i, list1_len, list2_len;
+ char *p;
+ char **newlist;
+
+ for (list1_len = 0; list1[list1_len] != NULL; list1_len++)
+ p = list1[list1_len];
+
+ for (list2_len = 0; list2[list2_len] != NULL; list2_len++)
+ p = list2[list2_len];
+
+ newlist = malloc(sizeof(char *) * (list1_len + list2_len));
+ if (newlist == NULL)
+ return(NULL);
+
+ for (list1_len = 0, i = 0; list1[list1_len] != NULL; list1_len++, i++)
+ newlist[i] = list1[list1_len];
+
+ for (list2_len = 0; list2[list2_len] != NULL; list2_len++, i++)
+ newlist[i] = list2[list2_len];
+
+ newlist[i] = NULL;
+ return(newlist);
+}
#if 0
--N/GrjenRD+RJfyz+
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
--N/GrjenRD+RJfyz+--
Robert E. Bruccoleri
>
> Please keep in mind that I was replying to a poster who said "cross-db
> queries on the same server (meaning same postmaster, for our purposes)
> are trivial; why hasn't Postgres got them when everybody else does?"
My apologies for missing that context.
> Your above arguments are all good ones, but they presume a scenario that
> is much different and *MUCH* harder to implement than local "cross
> database" queries. My point is that schemas solve the same-server
> problems that the original poster was interested in. I did not say,
> nor mean, that there is no need for cross-server queries. But that is
> a different problem. Today we can only offer dblink; maybe someday
> SQL-MED.
Agreed. Thanks. --Bob
+-----------------------------+------------------------------------+
| Robert E. Bruccoleri, Ph.D. | email: br...@acm.org |
| President, Congenomics Inc. | URL: http://www.congen.com/~bruc |
| P.O. Box 314 | Phone: 609 818 7251 |
| Pennington, NJ 08534 | |
+-----------------------------+------------------------------------+
Ron Mayer
Bruce wrote:
>Having good reference sites is important, and I could list as many
>impressive ones as MySQL, but who has time to hunt around and get
>permission to list them --- I will tell you who --- the MySQL marketing
>guys, while the PostgreSQL guys don't. :-(
Is it a good enough benefit to make the ones we already
have easier to find?
If the content on these pages:
http://techdocs.postgresql.org/techdocs/supportcontracts.php
http://advocacy.postgresql.org/casestudies/
http://archives.postgresql.org/pgsql-announce/2002-11/msg00004.php
could be integrated and put on an easy to find page in the
advocacy area it'd be a lot easier for new people to see.
I know PostgreSQL's got at least as impressive a list as MySQL. It's
just that you need to dig harder to find it.
Ron
Nigel J. Andrews
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > In fact I think postgresql is easier to use. Till date, I could never start
> > mysql by hand and get it behave sanely. pg_ctl or nohup postmaster has always
> > worked for me.
>
> This is weird, because despite mysql's technical inferiority, it really is
> pretty simple to use. Also seems a little hypocritical of you in light of
> the RTFM rant later on in your email. :)
I hate to join in this thread but...
I don't find it weird. It's probably a different mind set or something but I
find the MySQL documentation discussing something that will be in version 8.34
when they still list 3.23 as the latest production version is so confusing when
it's written with no indication that the thing isn't already in place.
Just my own view. People say MySQL is easy and PostgreSQL is difficult to
learn. I say PostgreSQL is easy and MySQL is difficult to learn.
And as for it being maintenance free while a regular vacuum is something too
difficult a concept for people to grasp. Well, what do these maintenance free
MySQL folk do with the regular tasks that MySQL needs run?
--
Nigel Andrews
Ian Barwick
> I hate to join in this thread but...
me too, but I am suffering from a bout of MySQL :-(
(...)
> Just my own view. People say MySQL is easy and PostgreSQL is difficult to
> learn. I say PostgreSQL is easy and MySQL is difficult to learn.
Having had to use MySQL seriously for the first time for a long time, I am =
finding
it makes the easy things (appear) easy and the difficult things impossible.
For example, AUTO_INCREMENT is easy to set up and use, but=20
is a toy feature compared to real sequences...
> And as for it being maintenance free while a regular vacuum is something
> too difficult a concept for people to grasp. Well, what do these
> maintenance free MySQL folk do with the regular tasks that MySQL needs ru=
n?
This is what MySQL recommends:
http://www.mysql.com/doc/en/Maintenance_regimen.html
How about repackaging VACUUM as a "database defragmentation
utility"? After all many many people have come to accept
disk defragmenters as an essential part of their OS ;-)=20
Ian Barwick
bar...@gmx.net