Please bear with me on this one. I'm not suggesting Slackware *should* include PostgreSQL as a default package - as I don't even know how popular, statistically, it is with people running Slackware boxes.

I am just curious as to why PostgreSQL is not included. I personally prefer it over MySQL - as it always seemed closer to the open source/free software spirit than other free databases - and less influenced by various political and commercial interests. It also seems to score high on the security and functionality front - at least as far as I can tell. So I use it everywhere I can by removing MySQL on my Slackware boxes and either manually compiling it from source or using SBo scripts. And it's been doing a damn fine job so far.

I've always vaguely wondered why it isn't included in Slackware. To my mind it seems like the sort of package that would go well with Slack.

FYI, MySQL has been replaced by MariaDB in -current, so future versions will not ship anymore with MySQL. Why there is no PostgreSQL is a question that I think can only be answered by PV.

Well, over the years, Slackware has been complete without bloat -- you've got enough un-fooled-around-with software to do pretty much anything you need to and it's easy enough to add whatever you'd like to fit some purpose. The DMBS model has been LAMP; MySQL was there, it worked (most of the time anyway) and with Slackware, Apache, MySQL and PHP you had a platform that, well, worked (and still does).

PostgreSQL is more or less a later bloomer -- and it is a danged good DBMS. I come for a long (like 30+ years) history with Informix (and still do data base design and development with it) and my initial impression of MySQL was... let's say sort of primitive when compared to Informix (Informix started out running just fine on Z-80 boxes and today runs, the same, on pretty much every platform known). But my initial (and continuing) impression of PostgreSQL is that it looks and feels a whole lot like Informix when it comes to setting up, configuring, interface and a bunch of the other stuff you deal with all the time. Frankly, I like PostgreSQL over MySQL and have switched quite a few applications over; however, MySQL is the DBMS of choice for many or even most applications you find useful out there in the world (some go both ways, many, many more are MySQL only and that's pretty much that). It's changing, slowly, but it seems like you can pick one or the other with a lot of the applications I'm adopting for one reason or another.

With Oracle tanking over MySQL (and the developers subsequently forking MariaDB) things are a'changing and we don't know just what kind of mess that's going be -- Oracle has a long history of making a mess of things (thankfully, Oracle gave OpenOffice to the Apache Foundation which may result down the road in a re-merge of LibreOffice and OpenOffice which I believe would be good for everybody -- the last thing Linux needs is those controversies holding up adoption). Along the same lines, I'd like to see Oracle give Java to somebody competent too.

But back to the subject. PostgreSQL's installed base has been growing (rather rapidly), it's nowhere near MySQL's installed base but it appears to be more of a choice for new installations (an InfoWorld article: http://www.infoworld.com/d/open-sour...tgresql-197584 might be interesting). And, as you know, if you want it, you can get quickly and easily (thanks to the great folks at SlackBuilds.org).

Taking all the folderol into account, the day may come that MySQL goes the way of the dodo bird and something else will take its place: MariaDB? PostgreSQL? Something else? Who knows. Today, MySQL is solid and dependable, so's PostgreSQL, and there's no sign that Slackware is going to switch one for the other, perhaps we just have to wait and see?

Hope this helps some.

1 members found this post helpful.

Like a couple of earlier posters, I use Postgres and never use MySQL/MariaDB servers, but I really don't mind 'only' getting Postgres from SlackBuilds.

I think popularity is a good explanation.
However, I see that here:
http://pkgs.org/slackware-13.37/slac...4-1sl.txz.html
there is a compiled postgresql binary.
It's been eons since the last time I used SlackWare, but it looks to me as a smaller (in size) distro with a particular audience. I have used postgresql on debian without any issue for some time, and it rocks.

I use PostgreSQL on all my boxes, in addition to MariaDB (aka MySQL). ;-)

I always build it from SBo script and don't mind that it is not included in Slackware.

It is neither a replacement for MySQL nor an either/or proposition, but MySQL is part of the LAMP stack plus an increasing requirement for KDE from what I have seen (not a KDE user), so having MySQL (aka MariaDB) included and PostgreSQL as an user addition seems the best mix.

As with many things, those who don't use it will never miss it, and those who do will probably build it themselves anyway.

That question has puzzled me also, but I never forced myself to ask.
Really, how come PostgreSQL is not included in Slackware?
Since other obscure software is included, such as Virtuoso (http://slackware.osuosl.org/slackwar...1.3-i486-3.txt), it can't be to avoid bloat and it can't be blamed on popularity either.

Don't get me wrong, I'm not blaming anyone here. Just that is strikes me as a curious fact to omit maybe the 2nd most popular OSS database and include Virtuoso? really?

PS. I have nothing against Virtuoso, I have never used it, I have never heard anyone using it and I've been around long enough to have programmed in COBOL and FORTRAN, but then again I only live in a small pond!

Virtuoso is the backend database for nepomuk in KDE, so it is required in Slackware.

AFAIK KDE relies on Virtuoso, so that's probably the reason why it's included with Slackware. BTW, Virtuoso appears to be an XML document database, while PostgreSQL and MySQL/MariaDB are SQL servers and store data records. They cannot really be compared with each other.

Regarding PostgreSQL compared to MySQL: PostgreSQL is a full-blown relational database management system (DBMS) that adheres to written SQL standards to a large extent. If you grab an arbitrary general SQL text book and type in some of the code examples, you'll get exactly the expected result, most of the time. Try the same with MySQL and you'll fail almost always.
What is more, PostgreSQL documentation is among the best you can get, and includes clear hints, where the PostgreSQL command syntax or behaviour deviates from the SQL-92 standard. Finally, PostgreSQL comes with some (proprietary) extensions that make it the DBMS for certain applications, such as geometric data. Applications, such as PostGIS, are therefore based on PostgreSQL (and even indicate that proudly in their name).

MySQL (and MariaDB) on the other hand, score with simplicity. MySQL or MariaDB may be a good choice for you, if you don't want to port your application to another platform or database backend, and if you don't want to dive into the intricacies of DBMS administration. Also, in some specific scenarios MySQL/MariaDB are faster and scale better than PostgreSQL. Most web applications don't need the full functionality of a full-blown DBMS, and something like MariaDB is certainly lower on resources than a "real" SQL server. This is, why MySQL (and in the future probably MariaDB) is supported by most web hosters, which makes LAMP, in turn, so popular among PHP web developers. And if more performance is required, there are complete and mature cluster management solutions available for MySQL.

PostgreSQL has made strides to catch up, but it's easier for an unexperienced programmer to take down a complete machine with just a wrong SQL statement. That's what web hosters are afraid of, at least, and why they usually don't offer PostgreSQL as an option for your own application development. They believe (right or not), MySQL/MariaDB is easier to control and manage.

BTW, PostgreSQL has been originally derived from Ingres, which is considered the most feature complete open source DBMS, currently.

gargamel

@allend: I didn't know that, but then again I don't use KDE.

@gargamel: I'm not comparing databases on technical merits, but the choice of including MySQL/MariaDB must have been based on something, why that something cannot be applied to PostgreSQL?. Since I regard databases to be an extremely useful component of any modern OS the inclusion of MySQL/MariaDB is very much welcomed. Maybe PostgreSQL is not included because it is not required by any of the existing packages that ship with Slackware. That is a valid reason and one that I can live with.

BTW, you don't need a database to bring a (default) Slackware box down.
Try:
in your shell prompt, but you already knew that didn't you!

Don't know if I'd agree with the proposition that MySQL is not a full-blown DBMS, I've yet to run into anything with MySQL that can't be done and that appears to function efficiently. I'd say the same for PostgreSQL. Too, I tend to stick with ANSI/ISO SQL (with both both DBMS') and I don't have problems (the one example I can think of is the create table syntax -- both DBMS' are perfectly happy with ANSI/ISO syntax or with their own -- MySQL's own being, to my eyes, a bit more convoluted).

I particularly like PostgreSQL's C interface (it looks a great deal like a port of Informix's ESQL/C preprocessor), where MySQL's API is... well, let's say awkward(?). The ability to embed SQL in a C program is, to my mind, a significant befefit.

I think that the bottom line is that they both work and they work well. The LAMP model provides solid, dependable rules of the road for MySQL in web applications, not so much with PostgreSQL (but getting there, methinks). For the long haul, I'd be more inclined to give the nod to PostgreSQL, rather than MySQL simply because we don't know what Larry Ellison is going to do (or when or how or why) and the developer fork to MariaDB... well, maybe, maybe not and a good, solid, dependable product is gone from the universe.

MySQL has been part of Slackware for quite awhile.

Replacing it with MariaDB makes perfect sense, as it is a drop in replacement, PostgreSQL is not. So far MariaDB has fit the bill as a replacement with my former MySQL databases.

Being a former Sybase user it took some getting used to using MySQL. I have never used PostgreSQL so I cannot comment on that aspect. If I had my druthers (and boat loads of cash) I'd go with Sybase, simply because I know it best.

1 members found this post helpful.

At my current employer, we use Postgres mostly because of the availability of LGPL'd client libraries. If our use were limited entirely to a datacenter, it wouldn't matter, but since we sell customers hardware with our software on it, it matters rather more.

I find the client cli rather more of a pain to use than MySQL's, but it's gotten a *lot* better than the last time I used it (2007). The SQL we use is fairly generic, and would work just as well under MySQL, Postgres, or sqlite (which we use for some unit tests in lieu of a Postgres instance, so it really is the same SQL being run through sqlite as Postgres).

My previous employer, DiscoveryMining, used MySQL for managing ETL metadata for a cluster of 500 servers. It served very well in that role. It scaled nicely in both sharded and master + multiple slave arrangements.

At archive.org, too, we used MySQL for ancillary stuff -- the data itself was served directly from the filesystem, but we used databases for things like user authentication, keeping track of which data servers were actively being filled, task queues, etc.

The only time MySQL bit us was when someone who shouldn't have had administrative access to the database at all, went and did something stupid -- like, improperly promote a slave to the master role when the master went down, which made one hell of a mess. Postgres has added replication solutions (like Tungsten) which make this sort of thing a bit easier and less prone to foot-shooting.

I made and ran some benchmarks of MySQL vs Postgres while at archive.org, and while their performance depended very much on configuration and schema, I concluded that for our particular workload Postgres scaled about 20% better than MySQL in terms of rows in a table. Every RDBMS has an inflection point, where SELECT performance becomes dramatically, nonlinearly worse as a table gets larger. In my benchmarks, MySQL reached that inflection point slightly sooner than Postgres.

Twenty percent is twenty percent, but I was looking to store rows two orders of magnitude beyond that inflection point, which meant a sharded solution. Once a solution requires sharding (which was done manually back then), the scalability of a single database instance matters much less, and since MySQL was easier to configure and use, I went with MySQL (which was fine).

That was 2007, and both RDBMSs have changed quite a bit since. I've been meaning to re-run those benchmarks and see where the inflection points sit today. If I get to it soon, I'll post them here.

Now as to the topic -- should Postgres be in Slackware? I don't see that it much matters. MySQL used to be the popular choice, but recent sentiment has turned in Postgres' favor. This seems more faddish to me than anything else. The differences between the two (client-side data validation vs server-side, etc) are fairly insignificant except to pedants. Googling for "why does MySQL suck" turns up many criticisms, most of which are either overblown, obsolete, or outright wrong.

My only concern is that adding Postgres would add to the Slackware team's maintenance burden. Would people prefer to have Postgres included, if it meant stretching PV + friends' scant hours even thinner than they already are? It would mean slightly more bugs in releases, and/or more time between releases.

Pruning some of the other maintenance-intensive packages from the distribution would help alleviate this burden, of course, but that's a topic of another thread.

1 members found this post helpful.

You must not do a lot with database triggers.

If you scroll to the bottom of https://downloads.mariadb.org/ you see LGPL client libraries for C and Java. Just raising awareness as they are rather new

1 members found this post helpful.