Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> On Sun, 26 Jul 1998, Herouth Maoz wrote: > > > At 23:36 +0300 on 24/7/98, Richard Lynch wrote: > > > > > > > Well, let's try crontab -e and mess around to find out the answers to these > > > questions. Or at least to see if I can just ignore this whole MAILTO thing > > > for now. I can always do crontab -r and blow it away. > > > > I nearly fell off my chair laughing... You know, on my personal TODO list > > there's a little item "Write crons for VACUUM", which has been there for > > months, and I keep postponing it. > > I'm another one of those people... so I wrote a quick & dirty c program to > vacuum ALL my databases. I just mailed it to Marc Fournier > ([EMAIL PROTECTED]) because I didn't know what to do with it, but if anyone > else wants it just drop me a line directly. > Here is a little shell script to do it. -- Bruce Momjian | 830 Blythe Avenue [EMAIL PROTECTED] | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup.| (610) 853-3000(h) psql -l -A -q -t|cut -d"|" -f1 | while read DATABASE do psql -q -c vacuum $DATABASE done
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> > > >Let's remove the "I don't want to think" utilities like
> > > >{create,destroy}{db,user} and force DBA's to actually use the *proper*
> > > >functions.
>
> IMHO (actually make that IMVeryHO) This is probably a bad idea... We
> should just update the man pages to detail the SQL code that can be used
> instead of the command. It doesn't hurt anything/anyone to leave the
> programs as they are, and can even be helpful to people writing scripts to
> automate management of their servers.
man pages already updated.
--
Bruce Momjian | 830 Blythe Avenue
[EMAIL PROTECTED] | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup.| (610) 853-3000(h)
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
>On Fri, 24 Jul 1998, Richard Lynch wrote: > >> At 8:28 AM 7/24/98, Marc Fournier wrote: >> >> >So, essentially, our VACUUM command provides functionality that >> >Oracle *doesn't* have, right? >> >> Yes, but yours doesn't run automatically. >> >> >> Ideally, when one created a database, one could specify vacuum frequency >> and/or time slot, and PostgreSQL would just do it... >> > >That's actually a good thought. Once we have it so that table-space is >re-usable (ie. fill in the blanks), then going one step further and having >something similar to that to 'vacuum' out fragmentation would be most >cool... Maybe I'm just still being naive, but I'm not seeing the dependency of automation of vacuum on table-space reusability. Or is it just that the there's only one hacker who can do it, and table-space reusability is way more important? [Oui. D'Accord.] If there is a dependency, I'd be interested in learning what it is. If it's just a man-power thing, then I'm just wasting your time. Sorry. PS: I checked the "\h create database" It don't say nothin' about needing to connect to template1 to create a database, nor does it say that it will copy the current database as a starter, which may or may not be true... The docs at postgresql.org also don't say nothin' about connecting to template1. -- -- -- "TANSTAAFL" Rich [EMAIL PROTECTED]
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> I think only doing it the SQL way would be fine. Documentation would, of > course, have to cover it That last sentence says it all..."Documentations would, of course, have to cofver it." The reason I used createdb to generate the my database, is that is what the man page said to do. Unfortunately it is hard to search in the man pages for something like: How do I create a database?. I think I came accross the createdb man page via the postgres man page's see also section...james
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
At 8:28 AM 7/24/98, Marc Fournier wrote: >So, essentially, our VACUUM command provides functionality that >Oracle *doesn't* have, right? Yes, but yours doesn't run automatically. Ideally, when one created a database, one could specify vacuum frequency and/or time slot, and PostgreSQL would just do it... -- -- -- "TANSTAAFL" Rich [EMAIL PROTECTED]
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Fri, 24 Jul 1998, Richard Lynch wrote: > At 8:28 AM 7/24/98, Marc Fournier wrote: > > >So, essentially, our VACUUM command provides functionality that > >Oracle *doesn't* have, right? > > Yes, but yours doesn't run automatically. > > > Ideally, when one created a database, one could specify vacuum frequency > and/or time slot, and PostgreSQL would just do it... > That's actually a good thought. Once we have it so that table-space is re-usable (ie. fill in the blanks), then going one step further and having something similar to that to 'vacuum' out fragmentation would be most cool...
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Fri, 24 Jul 1998, The Web Administrator wrote: > The boys at Postgres have so far done a good job of creating an effecient > Database, let's keep it that way, rather than created a Clone of some > commercial software that might have years of compatibility issues that > forced implementation of methods that may not be the most effecient.. > So let's stop comparing Postgres to the rest.. If there is something we > need to do with our Databases that we can't, then these are the issues we > should address only.. PostgreSQL is the first real database server I've ever used. I've not used Oracle or Sybase or anything like that, so the only thing I can compare it with is desktop database systems like MS-Access, and all I can say is that there' s no comparison. :-) I don't want PostgreSQL to be like Access, nor anything else for that matter, but just be what it is. Brett W. McCoy http://www.lan2wan.com/~bmccoy --- "The Number of UNIX installations has grown to 10, with more expected." -- The UNIX Programmer's Manual, 2nd Edition, June, 1972
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
Herve Lefebvre wrote: > ---Marc Fournier <[EMAIL PROTECTED]> wrote: > > > > On Thu, 23 Jul 1998, The Web Administrator wrote: > > > > > Nope.. Oracle has a background process which re-allocates free > space..It does get > > > fragmented, and the only real way to unfrag is to export (dump) > and import.No Vacuum, > > > at least on 7.3.2 > > > > So, essentially, our VACUUM command provides functionality that > > Oracle *doesn't* have, right? > > I don't think any fragmentation occurs under Oracle, if dataspaces are > allocated on raw-devices (wich is a functionnality PG doesn't have). > Of course, most DBA's I know never use raw devices, because of issues such as backups, etc... and even then, (but I am no expert here) I understand that data still gets fragmented because of it's implementation of data blocks, and it's rules for when to use the next block etc.. It has to allow for records which expand and contract, so it leaves room initially to allow for this so that records never span across two data blocks etc..Getting out my trusty Oracle Manual Under Fragmentation To determine the amount of fragmentation... select tablespace_name, sum(bytes), max(bytes), count(tablespace_name) from dba_free_space group by tablespace_name order by tablespace_name / If the number of contigous blocks is greater than 10 to 15, you should defrag the tablespace. The steps are 1) export data from the tablespace with the 'exp' utility. For indexes, capture the SQL to recreate them 2) Drop all the objects 3) Drop the tablespace 4) Recreate the tablespace 5) Import the data back into the tablespace with the 'imp' utility. Maunally recreate indexes by using their SQL scripts. Having sorted all that out... I think we should stop asking what 'Others' have, and just concentrate on making Postgres the best database out there, and let 'Others' implement Postgres Features.. IMHO, to often we are so intent on copying the 'Big Guys' that qwe forget out own strengths to the point that we start burdening clean code with garbage for compatibilities sake, rather than looking at it from scratch and seeing what the most effecient method is... The boys at Postgres have so far done a good job of creating an effecient Database, let's keep it that way, rather than created a Clone of some commercial software that might have years of compatibility issues that forced implementation of methods that may not be the most effecient.. So let's stop comparing Postgres to the rest.. If there is something we need to do with our Databases that we can't, then these are the issues we should address only.. It's like saying let's unix should use back slashes instead of forward slashes.. just because that is what windows/dos does... Or that we should recode Ultima to use a Doom perspective... Let Postgres stand on it's own merits, and not it's Oracle Compatibility.. Imagine what would have happened if Linus Torvald whould have decided that Linux needed to be Windows compatible.. The code would not have been the work of art it is today.. Well enough editorializing.. That's my last note on the Postgres vs. the rest argument.. -- ++ Michael - System Administrator Working in Cheap Canadian Dollars Unix Administration - WebSite Hosting - Network Services - Programming Wizard Internet Services - TechnoWizard Computers - Wizard Tower TechnoServices -- (604) 589-0037 Beautiful British Columbia, Canada ++
Re: [DOCS] Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Fri, 24 Jul 1998, Bruce Tong wrote: > > They have to connect to template1 to do the work. Currently, they don't > > need to know template1 even exists, so it seems like an added burden. I > > will add a mention to the createdb, destroydb man pages. createuser > > does psql too. > > And as a result, I didn't know what template1 was for until now, and I > fear there's more to it than just this. Up until this point, I assumed > "template1" was an example database which could be copied, or something. > At least that's what a template is to me. In a sense, that is exactly what it is. When you do a 'createdb', it uses template1 as the "template" for the new database, and then buildds from there...
Re: [DOCS] Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> They have to connect to template1 to do the work. Currently, they don't > need to know template1 even exists, so it seems like an added burden. I > will add a mention to the createdb, destroydb man pages. createuser > does psql too. And as a result, I didn't know what template1 was for until now, and I fear there's more to it than just this. Up until this point, I assumed "template1" was an example database which could be copied, or something. At least that's what a template is to me. Okay, I've suspected there was more to "template1" for a little while now, but I'd not gotten around to looking into it more. Still, my first impression was it was a sample database. ;) Maybe a name like "master" would be clearer, or maybe that means something else to someone. Bruce Tong | Got me an office; I'm there late at night. Systems Programmer | Just send me e-mail, maybe I'll write. Electronic Vision / FITNE | [EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
Re: [DOCS] Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> > >> In fact, they are handled by SQL: CREATE DATABASE and DROP DATABASE. The
> > >> createdb and destroydb tools just call these SQL statements
>
> > >Let's remove the "I don't want to think" utilities like
> > >{create,destroy}{db,user} and force DBA's to actually use the *proper*
> > >functions.
>
> > While the man pages indicate that these invoke psql, and that a postmaster
> > must be running, and somebody really smart could infer that that means that
> > there is SQL to do the action, it would be much, much better if the man
> > pages explicitly stated that it was merely a shortcut to using the sql.
>
> I think only doing it the SQL way would be fine. Documentation would, of
> course, have to cover it. I want, no need, to know what functionality
> belongs to SQL and what belongs to PostgreSQL. I've certainly not got any
> qualms about dropping into psql to do things. I like psql.
They have to connect to template1 to do the work. Currently, they don't
need to know template1 even exists, so it seems like an added burden. I
will add a mention to the createdb, destroydb man pages. createuser
does psql too.
--
Bruce Momjian | 830 Blythe Avenue
[EMAIL PROTECTED] | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup.| (610) 853-3000(h)
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> >> In fact, they are handled by SQL: CREATE DATABASE and DROP DATABASE. The
> >> createdb and destroydb tools just call these SQL statements
> >Let's remove the "I don't want to think" utilities like
> >{create,destroy}{db,user} and force DBA's to actually use the *proper*
> >functions.
> While the man pages indicate that these invoke psql, and that a postmaster
> must be running, and somebody really smart could infer that that means that
> there is SQL to do the action, it would be much, much better if the man
> pages explicitly stated that it was merely a shortcut to using the sql.
I think only doing it the SQL way would be fine. Documentation would, of
course, have to cover it. I want, no need, to know what functionality
belongs to SQL and what belongs to PostgreSQL. I've certainly not got any
qualms about dropping into psql to do things. I like psql.
Bruce Tong | Got me an office; I'm there late at night.
Systems Programmer | Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE |
[EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Thu, 23 Jul 1998, The Web Administrator wrote: > Nope.. Oracle has a background process which re-allocates free space..It does get > fragmented, and the only real way to unfrag is to export (dump) and import.No Vacuum, > at least on 7.3.2 So, essentially, our VACUUM command provides functionality that Oracle *doesn't* have, right? Marc G. Fournier [EMAIL PROTECTED] Systems Administrator, Acadia University "These are my opinions, which are not necessarily shared by my employer"
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
>> Oracle now comes along and says that it is going to have a
>> Linux-binary distribution available. So? How much is that binary
>> going to cost? And what sort of licensing is provided?
JohnDz> What version of Linux? What Platform ? Full featured?
I was asking myself the same question.
JohnDz> Don't kid yourselves about Oracle...
JohnDz> There are countless versions of Linux out there, running on
JohnDz> every platform ever invented.
Without starting a Linux-advocacy debate, I take exception to the
above statement :) I am under the impression that many of those Linux
ports are still rather experimental, and that there are still zillions
(!) of architectures that /don't/ yet have a Linux port. Please
educate me if I am wrong!
\begin{rant}
One of the reasons I work with NetBSD is that it has /stable/ ports to
more than a dozen different architectures (CPUs) and even more
platforms (types of machines)! I use two of them: i386 and MIPS/PMAX,
with a third in the running (waiting for some hardware): Mac68K.
I realise that there are people running Linux on Intel-based palmtops,
but that sort of thing is also happening with both NetBSD and FreeBSD.
Fair enough, Linux 2.x might have had much of the i386-specific guts
of Linux 1.x ripped out of it and replaced with more portable innards,
but NetBSD was built with that portability and code cleanliness from
the ground up! Having looked at the source code for large chunks of
Linux and that for equivalent chunks of NetBSD, I know without a
shadow of a doubt which way I choose to favour!
Enough said, I really don't want to start a useless advocacy debate, I
acknowledge that the Linux phenomenon is fabulous---every bit as
fabulous as NetBSD's implementation---yet I feel that the rest of the
free UNIX community is neglected when Linux gets all the spotlight!
\end{rant}
PostgreSQL runs quite nicely on NetBSD, thank you very much, though I
have not yet the time nor the requirement to stress it very much---I
/did/ have a go with the embedded-SQL C preprocessor, and I conclude
from that experience that in comparison against the embedded-SQL
preprocessor for the InterBase product, ecpg produces very elegant C,
and is, in many ways, a far nicer tool. On the other hand, the
InterBase tool implements a few more facilities, and as the DB of
choice for the project on which I am working those facilities had
precedence over my developing against PostgreSQL :(
JohnDz> Oracle would have to release source code ( ha ha) to be a true
JohnDz> linux port. I run LinuxPPC on a power mac, and if they port to
JohnDz> this then I will eat a huge plate of crow.
Here, here!
--Kevin.
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
[EMAIL PROTECTED] (The Hermit Hacker) writes: | Alot of good points here, and some not so good...last I checked, vacuum was | still required for Oracle, no? Does Oracle even have a vacuum? There's the COELESCE command, but it's hardly *necessary*. | As for 'front end and report designers'...there are several of them out there | currently, most, from what I've seen, *look* good. A lot of them "look good" at first glance. The problem seems to be that the implementations tend to be spotty and incomplete amongst the packages I've looked at. None of them are robust or complete enough for most commercial use. | If there are features within those that you feel are missing, talk to the | authors, offer to help... I'm only speaking from one viewpoint: is the product something I can recommend for commercial use to my customers in the same breath as Oracle or Informix? Would *I* use it, personally? Of course; I like it, and don't mind getting my hands dirty. But most companies would balk. They aren't balking at Linux or FreeBSD, nor are they balking at Apache, so it's not just an avoidance of open-source software. They *would* balk at the lack of features, in spite of PostgreSQL's cool stuff, and they'd also balk at the lack of facilities, and they'll *really* balk on the stability issues. | What I'd like to see, though, is a detailed version of your list above. For | instance, what locking issues? Low-level locking that Vadim is working on | for v6.4? I'm not clear on the details of what Vadim is working on, but if it's page- or row-level locking, that'd be it. However, it's hard to responsibly recommend something that hasn't been released yet. (Hasn't stopped Microsoft, but I try to be a bit more ethical than they are. :) | What analysis issues? If we could get the list above with explanations of | each, then Bruce can add them to the TODO list. Without explanations, some, | if not all, will sit there forever since nobody will understand *what* is | being asked :) Consider my wrist slapped. :) One thing I think that would psychologically help is to quit comparing PostgreSQL with mSQL and MySQL. The m*twins are cute, toy databases, and I suspect that the general perception is that PostgreSQL is already more serious than either one of those. So enough with those comparisons. Let's start thinking about comparing PostgreSQL with its *real* competition: Oracle, Sybase, SQL Server, Informix, and others. (Horrors! you say. "They're commercial products, how can we compete?" Apache still has more than 50% of the web market, Linux and FreeBSD are serious competitors to Solaris and HPs. So we don't have millions of dollars for marketing. So we don't have hundreds of developers to throw at a project. We have something *else* they don't have: a bunch of middle-management business-as-usual MBA-drones.) So. Let's talk features. (Hey! www.postgresql.org is reporting "Document contains no data." How am I supposed to pull up the TODO list like this?) Well, I'm gonna be guessing here, so please pardon me. Reliability: You don't need me to point out that a lot of work needs to be done here. These issues are tough ones to counter. Why doesn't pg_dump actually preserve everything? (It's getting better, I know, but it's not there right now.) Why do you have to vacuum the database every night? Questions like that are tough to answer to people's satisfaction, and that's without even going into things like memory leaks. Crucial basics: Views---they desperately need fixing up. Foreign keys, constraints, and SQL-language triggers are critical as well. I think HAVING, OUTER and INTERSECTS are being worked on. Temporary tables---are those being worked on? Yes, I know, most of these are on the TODO list already, but their current state of nonbeing is keenly felt, and hinders the cause quite a bit. The draws: These are the things that should be distinguishing PostgreSQL from the rest of the pack. The source code is a big draw, but it's still hard to grok. A concerted effort should be going on to document the code itself. Breaking out built-in types into their own easy-to-locate files would also be good, too; I had to work to find out how the box functions were defined, where it would have been better to have a built-in-types directory with a file in there named box.c, for example, with the data representation and the function source all neatly bundled---then it would be *easy* to use that as a template to come up with a different type. (Believe me, if datetime had had such a file, coming up with the equivalent of strftime() for that would have been a whole lot easier. As it is, I'm still trying to figure out how it's been implemented with what time I have these days.) There's a lot of clarification that could be done here as far as making it easy to add user-contributed stuff, which ultimately means that we can support more types---and that's a big draw. (Imagine a type called `eart
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> > > > What does Oracle's ODBC driver offer that ours currently doesn't? > > > > > > I just tried it for the first time last week. It failed to perform a > > > simple query. I need to double check my work yet. The Oracle ODBC driver > > > has _probably_ been around for a while and has _probably_ been better > > > tested perhaps simply by raw numbers of users. > > I bet he has the old PostODBC driver -OR- there is a configuration > issue. If the version of the driver he has begins with dot (like .21 > or .30), its ancient. > The latest version of the odbc driver at > http://www.insightdist.com/psqlodbc is 6.30.0247. While I was initially fooled by the old driver months ago, I have v06-30-0247 according to the installer, postdrv.exe. I got this from the web site you quoted. I'm fairly certain I can recreate the circumstances, and I'll try to do so today. I assume the "Interfaces" list is the place for this discussion. Bruce Tong | Got me an office; I'm there late at night. Systems Programmer | Just send me e-mail, maybe I'll write. Electronic Vision / FITNE | [EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> On Wed, 22 Jul 1998, James Olin Oden wrote: > > As far as documentation goes, I think that for the most part what is there is > > good. Sometimes (and I realize I need to be more specific) it seems the very > > thing you are looking for you can't find; in the end that generally has been an > > issue of inexperience with SQL. > > It seems to me that the documentation assumes some knowledge of SQL. > I don't know if this was intended or not, but if a new user DOESN'T > know anything about SQL, they are not going to learn it from the > PostgreSQL manuals. Here are some basic examples: > > The small section in the User's Manual on the SELECT command is > extremely short and neither explains nor gives examples for the many > basic things you can do with SELECT. So, for instance, from the > documentation, a new user will learn that he can select whatever > fields he wants from a table and tell it to select only those > records (tuples) which meet an exact criteria (suchandsuch < > 'soandso' AND blahblah = 'blah'). But let's say that he wants to > select NOT all records that contain only 'blah' in the blahblah > field, but rather, all records that have 'blah' ANYWHERE WITHIN the > blahblah field? No where in the PostgreSQL documentation (that I > could find) will he be told that he can do "blahblah LIKE '%blah%'". > > So now let's say he doesn't want it to be case sensative. Nowhere > that I could find do the manuals tell him that he can do "blahblah > ~* 'blah'". In fact, I didn't know that ~* even existed until > someone on the list suggested I do a "\do" in psql to get a list of > all the operators. Do you see how it seems like that information is > hidden down in an obscure help command in one program rather than > being right there in the User's Manual? What the User's Manual needs > is a nice long detailed description WITH A LOT OF EXAMPLES of the > SELECT command. Instead it seems to just mention it in passing. > > Now the man pages suffer the same problem that the entire man page > system suffers: it pretends to be an online representation of a > printed set of manuals, but it is missing one major feature of > printed manuals: A TABLE OF CONTENTS! Some of the man page info IS > in the HTML docs, but I think EVERYTHING in the man pages should be > in the HTML manuals, (possible better organized than man pages > allow). > > Most of the sections in the manuals are simply too brief. Consider > the section in the Tutorial on Redirecting SELECT Queries. It > explains the idea as quickly as possible, gives ONE example, and is > done. This doesn't help new users much. > > I think you see my point. If I knew more about PostgreSQL and SQL in > general, I'd offer to write some, but I'm just in the learning > process now. > Good points. The only comment I have is that the FAQ does now point to several SQL tuturials on the web, and the psql \d commands are mentioned as ways to find information about the system. We don't list them in the manual because they are always changing, because we are a user-extensible system. Every release has new types, so we just tell people to use the \d commands. I just improved them for 6.4 so the output is clearer. -- Bruce Momjian | 830 Blythe Avenue [EMAIL PROTECTED] | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup.| (610) 853-3000(h)
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
The Hermit Hacker wrote: > > On Wed, 22 Jul 1998, Bruce Tong wrote: > > > My comments are driven by perceptions. I admit they're uninformed. The > > topic is advertising PostgreSQL, so my perceptions are relevant. Educate > > me and the masses about your product. I'm hear because I think PostgreSQL > > is a useful tool. > > Perceptions from the 'admittedly uninformed' helps...:) > > > > > I say this with these (mostly uninformed) assumptions in mind. Oracle's > > > > ODBC driver is probably more complete. Oracle is better documented. Oracle > > > > has a lot of related tools. Oracle offers training. > > > > > > What does Oracle's ODBC driver offer that ours currently doesn't? > > > > I just tried it for the first time last week. It failed to perform a > > simple query. I need to double check my work yet. The Oracle ODBC driver > > has _probably_ been around for a while and has _probably_ been better > > tested perhaps simply by raw numbers of users. > I bet he has the old PostODBC driver -OR- there is a configuration issue. If the version of the driver he has begins with dot (like .21 or .30), its ancient. The latest version of the odbc driver at http://www.insightdist.com/psqlodbc is 6.30.0247. As long as we are mentioning the PostODBC, there is still a link under the "INFORMATION CENTRAL"-->"HOW TO"-->"INTERFACE DRIVERS FOR PostgreSQL"-->ODBC Drivers for PostgreSQL. This link takes you to "sunsite.unc.edu" which has outdated information on it. The ancient ODBC Drivers listed on this site are : stud1.tuwien.ac.at/~e9025461 www.MageNet.com/postodbc/DOC Is there anyway to correct this information and put the insight link on there? For that matter, is there anyway to point people who go to MageNet to the right address, like a forward page? This is important because Web search engines (yahoo, alta-vista) will still send you to MageNet if you search on odbc and postgres. I wonder how many people go try the MageNet odbc driver and just give up and try another dbms without even sending any mail to the lists? Please, I would really appreciate a response. Byron
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Wed, 22 Jul 1998, The Hermit Hacker wrote: > Oracle now comes along and says that it is going to have a > Linux-binary distribution available. So? How much is that binary going > to cost? And what sort of licensing is provided? I think PostgreSQL will continue on as much as before, just as Linux is continuing to put some competition to NT, because of its low cost and flexibility. Certainly many people will flock to Oracle, perhaps by corporate pressure, perhaps for the support or interoperability with other Oracle servers. But it's not going to kill off PostgreSQL. I'm happy that Oracle is being ported to Linux. I'll probably never use Oracle on Linux, but I think it will help get Linux wider recognition in the enterprise environment. And, how many 'supported platforms' of Oracle also support PostgreSQL? PostgreSQL isn't a Linux only server. > Continue our trend...continuing listening to the ppl asking for > various "reasonable" features and working towards providing them. I > support free/open software because, IMHO, the software is generally better > written, and more featured, because those that are developing it are doing > so because they *enjoy* what they are doing, they have a passion for > it...not because some large company is paying them to do it. A good point. Brett W. McCoy http://www.lan2wan.com/~bmccoy --- "The Number of UNIX installations has grown to 10, with more expected." -- The UNIX Programmer's Manual, 2nd Edition, June, 1972
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Wed, 22 Jul 1998, James Olin Oden wrote: > As far as documentation goes, I think that for the most part what is there is > good. Sometimes (and I realize I need to be more specific) it seems the very > thing you are looking for you can't find; in the end that generally has been an > issue of inexperience with SQL. It seems to me that the documentation assumes some knowledge of SQL. I don't know if this was intended or not, but if a new user DOESN'T know anything about SQL, they are not going to learn it from the PostgreSQL manuals. Here are some basic examples: The small section in the User's Manual on the SELECT command is extremely short and neither explains nor gives examples for the many basic things you can do with SELECT. So, for instance, from the documentation, a new user will learn that he can select whatever fields he wants from a table and tell it to select only those records (tuples) which meet an exact criteria (suchandsuch < 'soandso' AND blahblah = 'blah'). But let's say that he wants to select NOT all records that contain only 'blah' in the blahblah field, but rather, all records that have 'blah' ANYWHERE WITHIN the blahblah field? No where in the PostgreSQL documentation (that I could find) will he be told that he can do "blahblah LIKE '%blah%'". So now let's say he doesn't want it to be case sensative. Nowhere that I could find do the manuals tell him that he can do "blahblah ~* 'blah'". In fact, I didn't know that ~* even existed until someone on the list suggested I do a "\do" in psql to get a list of all the operators. Do you see how it seems like that information is hidden down in an obscure help command in one program rather than being right there in the User's Manual? What the User's Manual needs is a nice long detailed description WITH A LOT OF EXAMPLES of the SELECT command. Instead it seems to just mention it in passing. Now the man pages suffer the same problem that the entire man page system suffers: it pretends to be an online representation of a printed set of manuals, but it is missing one major feature of printed manuals: A TABLE OF CONTENTS! Some of the man page info IS in the HTML docs, but I think EVERYTHING in the man pages should be in the HTML manuals, (possible better organized than man pages allow). Most of the sections in the manuals are simply too brief. Consider the section in the Tutorial on Redirecting SELECT Queries. It explains the idea as quickly as possible, gives ONE example, and is done. This doesn't help new users much. I think you see my point. If I knew more about PostgreSQL and SQL in general, I'd offer to write some, but I'm just in the learning process now. Cheers. --Dan D. --- Daniel G. DelaneyThe Louisville Times Chorus [EMAIL PROTECTED] www.LouisvilleTimes.org www.Dionysia.org/~dionysos/ Dionysia Design ICQ Number: 8171285 www.Dionysia.com/design/ --- I doubt, therefore I might be.
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> Sometimes (and I realize I need to be more specific) it seems the very > thing you are looking for you can't find; in the end that generally has > been an issue of inexperience with SQL. Exactly. I'm learning SQL and PostgreSQL at the same time and it is sometimes difficult for me to correctly assess what belongs with each. My recent GRANT/REVOKE question was like this. I didn't think for a minute that would be handled by SQL since databases were created and destroyed by PostgreSQL utilities. > It seems to me, though, that there needs to be some sort of > documentation that takes a beginner write through the whole system step > by step and never leaving out the gory details, explaining things piece > by piece, until at the end of this the user has become an "expert". Yes! I'm the loan PostgreSQL user here. In fact, I'm the only person playing with a database. I'm the (completely unqualified) "expert" in the building. > Again, I need to be more specific, and as I mull over this I might be > able to be that, but now, I don't see documentation that is really > designed to take someone who doesn't know squat about SQL and get them > to the point where they are "experts". Perhaps that is not PostgreSQL's > problem, but it would be nice. > > Of course, if your write it, it doesn't mean they will read it ;-) Tutorials get read. References get read if they're organized well enough where the answer is found within a minute or two. Somebody who doesn't know the proper term still has to be able to find the answer. That's tricky, but those are the references which all people admire. Cross referencing is essential. One of my favorite parts of the man pages is the "See Also" section. This is because I usually get in the ball park on the first try, but not exactly to the right page. Bruce Tong | Got me an office; I'm there late at night. Systems Programmer | Just send me e-mail, maybe I'll write. Electronic Vision / FITNE | [EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> > > What does Oracle's ODBC driver offer that ours currently doesn't? > > > > I just tried it for the first time last week. It failed to perform a > > simple query. I need to double check my work yet. The Oracle ODBC driver > > has _probably_ been around for a while and has _probably_ been better > > tested perhaps simply by raw numbers of users. > > Have you mentioned this on [EMAIL PROTECTED]? David > and Bryon are both very vocal over there, and are quick to pop up to help > those using the ODBC drivers, as they are the ones that are developing it. Nope. I wanted to check my work first. Its my first attempt at using the ODBC driver and MS-Access has changed (for the worse interface-wise) a lot since v1.1. It may even have something to do with the way I've declared the tables on the PostgreSQL side. [ Documentation ] > Any comments, opinions or suggested changes is welcome...are you > on the pgsql-docs mailing list? No, but I will be shortly. > As for your perception of the documentation, have you [recently] checked > out: > > http://www.postgresql.org/docs It's been a few weeks. I'll look again. > My opinion, though, tends to be that I learn more from a book, > then from other ppl, except for clarification of what I've read... I too learn a lot from books. But on new subjects, a short class covering the idea behind the technology really helps. A little theory goes a long way. I can figure out the "How" if I know the "Why." Bruce Tong | Got me an office; I'm there late at night. Systems Programmer | Just send me e-mail, maybe I'll write. Electronic Vision / FITNE | [EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> > My experience with paid support vs mailings lists tends to have me > > much preferring mailing lists. At least on a mailing list, you have a > > good chance of finding someone that has already hit that same problem. > > Actually, I tend to end up supporting the product for which I am trying to be supported...not that that is bad ;-) Actually, most of my problems are answered before they happen, because I am constantly monitoring the list. As far as documentation goes, I think that for the most part what is there is good. Sometimes (and I realize I need to be more specific) it seems the very thing you are looking for you can't find; in the end that generally has been an issue of inexperience with SQL. It seems to me, though, that there needs to be some sort of documentation that takes a beginner write through the whole system step by step and never leaving out the gory details, explaining things piece by piece, until at the end of this the user has become an "expert". Again, I need to be more specific, and as I mull over this I might be able to be that, but now, I don't see documentation that is really designed to take someone who doesn't know squat about SQL and get them to the point where they are "experts". Perhaps that is not PostgreSQL's problem, but it would be nice. Of course, if your write it, it doesn't mean they will read it ;-) ...james
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
---Bruce Tong <[EMAIL PROTECTED]> wrote: > > features != ANSI SQL compliance, right? > > I suppose ANSI SQL is the heart of it. > > > Again, what are we missing that Oracle currently has...? > Stored procedures with tuples resultset: SELECT F1,F2,F3 FROM TABL1 And Multi-resultsets stored-procedures: SELECT F1,F2 FROM TABLE1 SELECT F3,F4,F5 FROM TABLE2 And how can we declare/use variables with PG-SQL ? With Sybase (and oracle) I can do that: PROCECURE p (@org_account int, @dest_account int, @amount money) as DECLARE @balance money BEGIN TRAN SELECT @balance=balance FROM account_table WHERE @account_num=@org_account /* Check if enough money on the account */ IF @balance<@amount BEGIN ROLLBACK TRAN RETURN -1 /* Not enough money */ END /* proceed with the updates */ ... COMMIT TRAN RETURN 0 go How to do a such stored procedure with pgSQL ? (please, don't say me to write it in C language ). -- H.L. _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> MPSQL: http://troubador.com/~keidav/images/screenshots/sot.jpg > MPMGR: http://troubador.com/~keidav/mpmgr.html > - if nobody has checked out the screenshots on this, > check it out This one is looking *sooo* cool. Anybody knows of a good toolkit the author can switch to? (he asks for suggestions on the page above). I think up till now it was motif based? Is lesstif already up to this kind of work? Is it easier to switch from motif to gtk than to switch to qt? > EARPII: http://www.oswego.edu/~ddougher/EARP2 > PGAccess: http://www.flex.ro/pgaccess > - does Forms, Reports and Scripts > PGAdmin: http://www.vale-housing.co.uk/it/software > - no screenshots, unfortunately :( > GtkSQL: http://www.mygale.org/~bbrox/GtkSQL > KPGsql: http://home.primus.baynet.de/mgeisler/kpgsql > - KDE frontend Maarten _ | TU Delft, The Netherlands, Faculty of Information Technology and Systems | | Department of Electrical Engineering| | Computer Architecture and Digital Technique section | | [EMAIL PROTECTED] | -
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Wed, 22 Jul 1998, Bruce Tong wrote: > My comments are driven by perceptions. I admit they're uninformed. The > topic is advertising PostgreSQL, so my perceptions are relevant. Educate > me and the masses about your product. I'm hear because I think PostgreSQL > is a useful tool. Perceptions from the 'admittedly uninformed' helps...:) > > > I say this with these (mostly uninformed) assumptions in mind. Oracle's > > > ODBC driver is probably more complete. Oracle is better documented. Oracle > > > has a lot of related tools. Oracle offers training. > > > > What does Oracle's ODBC driver offer that ours currently doesn't? > > I just tried it for the first time last week. It failed to perform a > simple query. I need to double check my work yet. The Oracle ODBC driver > has _probably_ been around for a while and has _probably_ been better > tested perhaps simply by raw numbers of users. Have you mentioned this on [EMAIL PROTECTED]? David and Bryon are both very vocal over there, and are quick to pop up to help those using the ODBC drivers, as they are the ones that are developing it. > > Have you looked at recent documentation? It has changed > > dramatically over the past couple of months... > > I like to think I check your docs regularly, but I'm sure there's stuff I > miss. From my experience documentation is examples, HOWTO's, web sites, > and man pages which are all good approaches. The trouble is there is no > place which coordinates this. Searches tend to be a brute force effort for > me because I do not yet understand how the material is organized. I'm sure > if you've been around PostgreSQL for a couple of years you know the sorts > of things to expect to find in the man pages. To me, I never would have > thought to search the man pages for GRANT and REVOKE, or any SQL for that > matter. > > In fact, documentation is probably the only place I can help your > development effort at this time since I cannot see the big picture. Hence, > the journal I'm keeping could be turned into a tutorial, which I suppose > it actually my goal. Any comments, opinions or suggested changes is welcome...are you on the pgsql-docs mailing list? As for your perception of the documentation, have you checked out: http://www.postgresql.org/docs recently? I've recently done a major cleanup of it so that the links there are presented a little more clearly, but there are 5 guide/manuals listed right at the top that you might find sligthly more informative those docs you list above... > > > What do you mean by "related tools"? > > Good question. What is Oracle Power Objects? What is Oracle/2000? I see > these things advertised. What do they do, and is an equivalent available > for PostgreSQL assuming it is a relavent product? I don't know, can't help you there...I don't use Oracle, so someone with experience in that area will have to pop up and help :) > > Training in...administration? We run it at my "real job", and > > Oracle *has* to offer training for administration...its a > > nightmare. > > Administration, yes. So far, my experience with PostgreSQL has been that 'administrative functions' tend to be few, but there is a Administrator's Guide that documents, I think, most of what you need to know. My opinion, though, tends to be that I learn more from a book, then from other ppl, except for clarification of what I've read... > > Again, what are we missing that Oracle currently has...? > > If you offer the same features, then list those features in a comparison > on your web site. Take a "See... we do everything Oracle does. Hasn't been updated in awhile, but see: http://www.postgresql.org/comp-comparison.shtml > That's my experience too. Notice I didn't mention paid support. My point > here is if there's a list for Oracle, then you are the same in this > category. That depends...we are only the same if you get similar support through the Oracle list as you do here...
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
---The Hermit Hacker <[EMAIL PROTECTED]> wrote: > > On Tue, 21 Jul 1998, Bruce Momjian wrote: > > > We clearly are the most advanced "open source" database around. We now > > have "closed source" competition. How do we meet that challenge? > > You want an honest answer? We don't. Or, at least, we don't > think of it as meeting a challenge. I agree, I think it's a bad news for Sybase, but a very good news for Linux. And if it's good for Linux, it's good for pgsql. -- Herve Lefebvre _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
My comments are driven by perceptions. I admit they're uninformed. The topic is advertising PostgreSQL, so my perceptions are relevant. Educate me and the masses about your product. I'm hear because I think PostgreSQL is a useful tool. > > I say this with these (mostly uninformed) assumptions in mind. Oracle's > > ODBC driver is probably more complete. Oracle is better documented. Oracle > > has a lot of related tools. Oracle offers training. > > What does Oracle's ODBC driver offer that ours currently doesn't? I just tried it for the first time last week. It failed to perform a simple query. I need to double check my work yet. The Oracle ODBC driver has _probably_ been around for a while and has _probably_ been better tested perhaps simply by raw numbers of users. > Have you looked at recent documentation? It has changed > dramatically over the past couple of months... I like to think I check your docs regularly, but I'm sure there's stuff I miss. From my experience documentation is examples, HOWTO's, web sites, and man pages which are all good approaches. The trouble is there is no place which coordinates this. Searches tend to be a brute force effort for me because I do not yet understand how the material is organized. I'm sure if you've been around PostgreSQL for a couple of years you know the sorts of things to expect to find in the man pages. To me, I never would have thought to search the man pages for GRANT and REVOKE, or any SQL for that matter. In fact, documentation is probably the only place I can help your development effort at this time since I cannot see the big picture. Hence, the journal I'm keeping could be turned into a tutorial, which I suppose it actually my goal. > What do you mean by "related tools"? Good question. What is Oracle Power Objects? What is Oracle/2000? I see these things advertised. What do they do, and is an equivalent available for PostgreSQL assuming it is a relavent product? > Training in...administration? We run it at my "real job", and > Oracle *has* to offer training for administration...its a > nightmare. Administration, yes. > > > features > > > > As many posts I see to this list are "how do I do this" - "not > > implemented, wait for a later version", I'm not sure why you would make > > this claim. Again, I'm not a person who spends a great deal of time on > > databases and I do consider myself uninformed. > > features != ANSI SQL compliance, right? I suppose ANSI SQL is the heart of it. > Again, what are we missing that Oracle currently has...? If you offer the same features, then list those features in a comparison on your web site. Take a "See... we do everything Oracle does." > > > support > > > > The mailing lists are nice. I appreciate them very much. There's probably > > a mailing list for Oracle. What more is there for support? > > My experience with paid support vs mailings lists tends to have me > much preferring mailing lists. At least on a mailing list, you have a > good chance of finding someone that has already hit that same problem. That's my experience too. Notice I didn't mention paid support. My point here is if there's a list for Oracle, then you are the same in this category. Bruce Tong | Got me an office; I'm there late at night. Systems Programmer | Just send me e-mail, maybe I'll write. Electronic Vision / FITNE | [EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> > Oracle now comes along and says that it is going to have a > Linux-binary distribution available. So? How much is that binary going > to cost? And what sort of licensing is provided? -- What version of Linux? What Platform ? Full featured? Don't kid yourselves about Oracle. Take it from someone who participates on a Linux Mailing list also: There are countless versions of Linux out there, running on every platform ever invented. Oracle would have to release source code ( ha ha) to be a true linux port. I run LinuxPPC on a power mac, and if they port to this then I will eat a huge plate of crow. - |John Dzilvelis | -
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Tue, 21 Jul 1998, Bruce Momjian wrote: > We clearly are the most advanced "open source" database around. We now > have "closed source" competition. How do we meet that challenge? You want an honest answer? We don't. Or, at least, we don't think of it as meeting a challenge. We've spent the past, what, 2 years now, building PostgreSQL up to something that we (the developers) are proud to work with and support, and are confident in both using, and promoting for use, in real, production environments. Oracle now comes along and says that it is going to have a Linux-binary distribution available. So? How much is that binary going to cost? And what sort of licensing is provided? How many ppl are going to flock to Oracle because all of a sudden they have a Linux port of it? I just checked their list of 'supported platforms', and here at the University, we run almost a half a dozen of them (Win95, WinNT, Solaris x86, Sparc/Solaris, Netware)...its not as if I don't have a machine that I can pay the same price for Oracle and run it on them... Continue our trend...continuing listening to the ppl asking for various "reasonable" features and working towards providing them. I support free/open software because, IMHO, the software is generally better written, and more featured, because those that are developing it are doing so because they *enjoy* what they are doing, they have a passion for it...not because some large company is paying them to do it. IMHO, the most important thing that is happening right now is Vadim's work at getting LLL in place for v6.4. To me, that is as important, if not more so, in a 'multi-user, concurrent' system as transactions are, as on a multi-user system, it would be a performance increase due to less ppl having to wait to make changes... I would like to see Ken's list of missing items expanded with explanations and added to the TODO list, as appropriate, since I think he brought up alot of good points, but I think that "panick'ng" because Oracle has announced an upcoming release of a Linux binary is counter-productive...
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Tue, 21 Jul 1998, Ken McGlothlen wrote: > There are a wide array of other issues, too; the simplistic security, > view limitations, administrational problems (eventually, for example, > vacuum should be unnecessary), analysis issues, replication issues, > cross-server database issues, index limitations, the lack of a good > front end designer, the lack of a good report designer, locking issues, > and so on. Alot of good points here, and some not so good...last I checked, vacuum was still required for Oracle, no? Its been awhile since I've looked at it from a DBA perspective, so this may no longer be the case... As for 'front end and report designers'...there are several of them out there currently, most, from what I've seen, *look* good: MPSQL: http://troubador.com/~keidav/images/screenshots/sot.jpg MPMGR: http://troubador.com/~keidav/mpmgr.html - if nobody has checked out the screenshots on this, check it out EARPII: http://www.oswego.edu/~ddougher/EARP2 PGAccess: http://www.flex.ro/pgaccess - does Forms, Reports and Scripts PGAdmin: http://www.vale-housing.co.uk/it/software - no screenshots, unfortunately :( GtkSQL: http://www.mygale.org/~bbrox/GtkSQL KPGsql: http://home.primus.baynet.de/mgeisler/kpgsql - KDE frontend If there are features within those that you feel are missing, talk to the authors, offer to help... What I'd like to see, though, is a detailed version of your list above. For instance, what locking issues? Low-level locking that Vadim is working on for v6.4? What analysis issues? If we could get the list above with explanations of each, then Bruce can add them to the TODO list. Without explanations, some, if not all, will sit there forever since nobody will understand *what* is being asked :) Some of them might be small, no brainer additions that nobody thought about...*shrug*
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
On Tue, 21 Jul 1998, Bruce Tong wrote: > I say this with these (mostly uninformed) assumptions in mind. Oracle's > ODBC driver is probably more complete. Oracle is better documented. Oracle > has a lot of related tools. Oracle offers training. What does Oracle's ODBC driver offer that ours currently doesn't? Have you looked at recent documentation? It has changes dramatically over the past couple of months... What do you mean by "related tools"? Training in...administration? We run it at my "real job", and Oracle *has* to offer training for administration...its a nightmare. > > features > > As many posts I see to this list are "how do I do this" - "not > implemented, wait for a later version", I'm not sure why you would make > this claim. Again, I'm not a person who spends a great deal of time on > databases and I do consider myself uninformed. features != ANSI SQL compliance, right? Again, what are we missing that Oracle currently has...? > > support > > The mailing lists are nice. I appreciate them very much. There's probably > a mailing list for Oracle. What more is there for support? My experience with paid support vs mailings lists tends to have me much preferring mailing lists. At least on a mailing list, you have a good chance of finding someone that has already hit that same problem...
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
That is my case: We have an Sun Ultra Sparc acting as a server for ~ 90 Pc runing M$ Dos or Windows, almost all playing with a CAD program. I and a few other people take care of the whole thing. We need a SQL server but it is very hard for us to have approved a budget of thousands of dollars to buy, traning and mantain a program like Informix or Oracle to run in our server when we have to buy computers and programs that runs CAD to allow ours engineers to work. So PostgreSQL realley save my life. It runs very well at Sun, I have a very good support from all of you and I do not need all the stuff Oracle or Informix offers. I am now makeing a program that controls all our project files (more than 50.000) that are acessed by people that works where.(It was based in DBF files). And the files and data will be accessible inside our office or outside through browsers (CGI etc ...). I will port a big calc program that will store all data into PostgreSQL. I see PostgreSQL not only as a program for PC runing Linux but also as a very good alternative for all unix box. Roberto > >OK, let's discuss this. How does this affect us? With all three >releasing around the same time, they really dilute themselves. I can't >imagine most people trying more than one of the commercial alternatives. > -- Eng. Roberto João Lopes Garcia E-mail: [EMAIL PROTECTED] F. 55 11 848 9906 FAX 55 11 848 9955 MHA Engenharia Ltda E-mail: [EMAIL PROTECTED]WWW: http://www.mha.com.br Av Maia Coelho Aguiar, 215 Bloco D 2 Andar Centro Empresarial de Sao Paulo Sao Paulo - BRASIL - 05805 000 ---
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
Bruce Momjian <[EMAIL PROTECTED]> writes: | OK, let's discuss this. How does this affect us? [...] | Certain people will be tempted by a commercial SQL server, while others | will prefer us because of: | | features Sorry, but I just don't buy this at the moment, for several reasons. Don't get me wrong. I like PostgreSQL, and think it could *eventually* kick butt, but (as always, IMHO) it's Not Ready for Prime Time yet, not by a long shot. Let's look at some of the most problematic issues at the moment: * No foreign keys. This is a real kicker for a lot of people. Foreign keys are a big data integrity issue. Fortunately, you can get around these with triggers, but: * No SQL-based triggers. Triggers have to be written in C, and this is a big showstopper for a lot of people. * No OUTER JOIN (left or right). Yes, you can simulate some of these with various UNION operators, but it's definitely off the SQL mainstream. * 32-bit OIDs. This pretty much takes PostgreSQL out of the running for large database projects. * Hard-to-grok source code. Open source is great, but PostgreSQL source code still has great swaths of uncommented stretches of code, and that makes it much more difficult to do things like add esoteric types, or even extend the functionality of existing types. I recognize that most of this is because it's still an amalgam of Postgres with the new stuff, but for PostgreSQL source to be a "selling point" of the software, it has to make the job of adding types and functionality *much* easier rather than merely possible. There are a wide array of other issues, too; the simplistic security, view limitations, administrational problems (eventually, for example, vacuum should be unnecessary), analysis issues, replication issues, cross-server database issues, index limitations, the lack of a good front end designer, the lack of a good report designer, locking issues, and so on. As I said, I like PostgreSQL. It could eventually be a serious competitor to Oracle. I'd love to see it do so. But this news of commercial competitors will certainly eat away at a good portion of PostgreSQL's commercial customers, and I can't see PostgreSQL reversing that trend unless 6.5 is a major leap forward. ---Ken McGlothlen [EMAIL PROTECTED]
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
[EMAIL PROTECTED] (Bruce Momjian) writes: | Consider what we are doing. Commercial database vendors have teams of | full-time programmers, adding features to their databases, while we have a | volunteer group of part-time developers. Oh! I'd never *dream* of maligning the coders working on PostgreSQL. For a volunteer grass-roots effort, PostgreSQL is a paragon of virtue---one of the reasons I like it. And writing complex database packages of this sort isn't exactly chimp-stuff, either---I think any of us would vouch for that. Ultimately, the crux of the matter is this: who are we *targeting* as our competition? If we're looking at the mSQL and mySQL camp, clearly PostgreSQL stomps them both, from both the SQL support side and the data-security side. (And yes, I'd agree that the code is *ever* so much neater than MySQL.) But if we're trying to position ourselves as a viable alternative to the big commercial ones, such as Oracle and Informix and Sybase and MS SQL Server, we need to work on a lot of issues. Open source is perceived in the business community as a big risk, and not a benefit. Even today, someone said to me, "Oh, that's all we need, some Linux guru spending three or four hours on compiling a new kernel rather than attending to his actual duties." (Yes, I'll be the first to admit that it was a stupid statement, but as a consultant, I can't just say, "What a stupid statement." It takes time to win over people like this; you have to throw a product at them that makes them go, "Geez, that was cool, and it saved us a lot of time and money.") | Fortunately, we have many features they don't have, which we inherited from | Berkeley. Yes. But at the moment, they have a bunch of *fundamental* features that we don't have. That's what worries me as far as general acceptance of PostgreSQL by the business community. | I have made it a personal project of mine to make it clear, so other people | can understand it and hence contribute. A lot more could be done. More comments. Breaking out individual datatypes into their own modules (ready-made templates for new types that require implementation in C!). But to your (and others') credit, it's gotten quite a bit cleaner just in the last year. | We clearly are the most advanced "open source" database around. We now | have "closed source" competition. How do we meet that challenge? If we can clear up some of the glaring lackings in PostgreSQL by year-end, I think it'll've been met pretty well.
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
> OK, let's discuss this. How does this affect us? With all three > releasing around the same time, they really dilute themselves. I can't > imagine most people trying more than one of the commercial alternatives. I offer myself up as a case study... I will likely use Oracle (or one of the other two) for some things, and PostgreSQL for other things. Where expense is the key issue for a customer, PostgreSQL. Where cost is less of a factor, Oracle. I say this with these (mostly uninformed) assumptions in mind. Oracle's ODBC driver is probably more complete. Oracle is better documented. Oracle has a lot of related tools. Oracle offers training. > Certain people will be tempted by a commercial SQL server, while others > will prefer us because of: > > features As many posts I see to this list are "how do I do this" - "not implemented, wait for a later version", I'm not sure why you would make this claim. Again, I'm not a person who spends a great deal of time on databases and I do consider myself uninformed. > installed base PostgreSQL coming preinstalled with RedHat Linux 5.1 was the sole reason I selected it. It was just too convenient. > open source While I can appreciate this, it is not a requirement. Without a background in database related knowledge, I would probably do more harm than good in the short term, and no time for a long term investment in changes. > support The mailing lists are nice. I appreciate them very much. There's probably a mailing list for Oracle. What more is there for support? > price(some are free) This is the significant advantage of PostgreSQL to me. Bruce Tong | Got me an office; I'm there late at night. Systems Programmer | Just send me e-mail, maybe I'll write. Electronic Vision / FITNE | [EMAIL PROTECTED]| -- Joe Walsh for the 21st Century
