Re: 16 parameter limit
От | Josh Berkus |
---|---|
Тема | Re: 16 parameter limit |
Дата | |
Msg-id | web-1050317@davinci.ethosmedia.com обсуждение исходный текст |
Ответ на | 16 parameter limit (John Proctor <jproctor@prium.net>) |
Список | pgsql-sql |
John, > Thanks for replying. I fear that I may have come off as whiny or > > ungrateful. I hope that I did not. I am extremely happy with > PostgreSQL > and would like to see it take root in enterprise business. Sorry. I tried to seperate my criticisms of the people you weretalking about (e.g. Oracle DBAs who can't be bothered toread themailing list) and you (who obviously *can* be bothered to read themailing list). Maybe *I* wasn't clear enough. >I work > with > oracle, sybase and mssql every day. Oracle is a nice database, but > it is > expensive and I am not interested in their new direction (Java this, > Java > that). 9i has about 2GB of jar files that I don't even want or > need, but I > still have to back them up because I am afraid to delete them. Hey! I like Java, personally. It's just that I don't often getprojects that are more intersted in comprehensive design asthey arein cost savings ... thus I do a *lot* of PL/pgSQL + PHP combinations. > Anyway, I understand your point about using a 3GL for the middle > tier data > access, but I don't see that happening on large projects. I know > there are > many java projects that did that and still do, but I haven't seen > many that > worked out well. Most large projects that I have seen and I am > involved in > use a complete stored procedure interface. The reasons are simple. > The > DBAs can design the database and provide the interface. The > developers only > need to understand the interface exposed by the DBA (stored procs). > It also > allows for multiple languages to use the same interface, which is > very > important when integrating with legacy systems. Also, compiled > PL/SQL runs > much faster than java/jdbc, and is much faster to develop and debug. > I can > also minimize bugs by not allowing developers to write directly to > tables. > I know that if my procedure interface is correct and few changes are > needed > to the data layer then changes to the display layer do not effect the > > database. However, this same logic does not seem to hold well with > the > middle layer. Middle layers tend to follow changes in the display > layer > which increases potential for bugs. Well, that's not the theory of n-tier development, but I'll agree thatreal, CORBA-compliant business objects are seldom implementedproperlyoutside of (perpetually unfinished) Open Source projects. Certainlythe advantage of a SQL scripting languageis that the person whounderstands the database best (the DBA) can implement business ruleswithout learning a completelydifferent programming lanuguage. Thiswas the reason for the termendous popularity of 4GL in its day (BTW,thereis a 4GL interpreter for PostgreSQL). > It has been my experience that most large oracle projects done by > good > professionals use PL/SQL extensively. That is why I think > PostgreSQL will > not penetrate this market unless it can allow developers to continue > using a > model that has proven to be successful. Yup. You gotta do what the customers want, or you don't capture them. Let me also reiterate my statement that I believethat Great Bridgemade a mistake trying to take on Oracle last year, and that Red Hat ismore astute going after theMS SQL market. > Please note that I am not someone just sitting around waiting for > others to > spend their time building my needs. I am involved in some other > projects > regarding open source. I am also not complaining. I just didn't > want > people to think that lack of questions regarding this meant lack of > need in > large companies. It is just that those people are not even looking > at > PostgreSQL right now. My only reason for bringing it up is my > desire to see > PostgreSQL move forward and so that I may (for selfish reasons) use > it in > some professional projects one day. See my first paragraph. If you want to pursue this (and I wish you would!) there's two ways togo: 1. Try to get the current major commercial PostgreSQL implementation,Red Hat's RHDB, interested in your suggestions. MichaelEvans at RedHat is in charge of RHDB. As far as I know, however, all of theirdevelopment effort is cocentrated onthe issues of replication, userinterface, and backup/recovery. 2. Work with me and other PL/pgSQL users to develop a laundry list ofPL/pgSQL improvements, and then recruit or hire a programmerorprogrammers to implement them. I would be happy to contribute specsand testing to such a project, but I don'tknow enough C to doanything useful. Preferably, we would find someone interested inbeing the ne PL/pgSQL lead so thatthe language can continue to moveforward indefinitely with a strong advocate and targeted goals forevery Postgres release. -Josh Berkus
В списке pgsql-sql по дате отправления: