Thread: Ridicolus Postgresql review
If you want to get angry, take a look at: http://www.iemagazine.com/010918/414feat3_1.shtml You will read a PostgreSQL review that has been made by a man that didn't even read the documentation (and surely didn't tried it...). I don't want to say that PostgreSQL is the best DB ever, but take a look at this: " Complex SQL, in the form of subqueries and correlated queries, are largely unsupported" (????) " However, unlike most commercial databases, users do not have the ability to create their own stored procedures" (what?) ... and so on... have fun. Best regards Andrea Aime
* "Andrea Aime" <aaime@comune.modena.it> wrote: | | If you want to get angry, take a look at: | " However, unlike most commercial databases, users do not have | the ability to create their own stored procedures" (what?) I can't find anything in the documentation in PostgreSQL on how to make a stored procedure return a result set. AFAIK it cannot and then it is not really fair to claim that pgsql has stored procedures. Some other goodies from the article : "PostgreSQL provides support for queries and data manipulation statements that span multiple database instances." "Both MySQL and PostgreSQL are multithreaded servers" But I agree, this author is a joke. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
Gunnar Rønning writes: > I can't find anything in the documentation in PostgreSQL on how to make > a stored procedure return a result set. AFAIK it cannot and then it is not > really fair to claim that pgsql has stored procedures. There seems to be a rather narrow view of what a stored procedure is. A procedure is just a sequence of statements collected under a name, possibly parametrized. "Stored" simply means that it's stored in the server. PostgreSQL supports both of these things just fine. A whole 'nother thing is the ability to return result sets from functions. OK, other vendors may call the latter for "stored procedures", but that is terminological nonsense. And going out there writing an article claiming that in PostgreSQL "users do not have the ability to create their own stored procedures", without further qualification, is confusing at best. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
* Peter Eisentraut <peter_e@gmx.net> wrote: | server. PostgreSQL supports both of these things just fine. A whole | 'nother thing is the ability to return result sets from functions. | | OK, other vendors may call the latter for "stored procedures", but that is | terminological nonsense. And going out there writing an article claiming | that in PostgreSQL "users do not have the ability to create their own | stored procedures", without further qualification, is confusing at best. That's not nonsense at all, you can't just go around and redefine the language used in the database world at your own whims. Everybody I know employed in the database arena thinks of a stored procedure as something that may return result sets. In PostgreSQL it cannot and does therefore not fit the term stored procedure. What is confusing is the PostgreSQL use of the term "stored procedure". To me it sounds like bad marketing, something we really shouldn't need in the open source world. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
> That's not nonsense at all, you can't just go around and redefine the
> language used in the database world at your own whims.
"Stored Procedure".. Hmm, that seems to me that the definition of that would
be "a procedure that's stored somewhere". When talking about stored
procedures and databases I would assume that the stored procedure would be
some database procedure (anything you can do with or in a database could be
seen as a procedure, IMHO), that's stored in the said database...
"Stored Procedure" is a very ambiguous term and probably needs to be treated
as such.. Unless there is a written definition somewhere that outlines
exactly how a stored procedure has to return things then I think PG's stored
procedures have the right to carry the name...
> Everybody I know employed in the database arena thinks of a stored
procedure
> as something that may return result sets. In PostgreSQL it cannot and
> does therefore not fit the term stored procedure.
What do they base that on though? The inability to return a record set from
a PG stored procedure is a limitation, no doubt, but not cause to say that
PG doesn't support stored procedures..
> What is confusing is the PostgreSQL use of the term "stored
> procedure". To me it sounds like bad marketing, something we really
> shouldn't need in the open source world.
I think PG is using the term as well as anyone could use such an
ambiguous term.. I think it's fair to list the limitations of PG stored
procedures when discussing feature sets but I don't think it's fair to say
that PG doesn't have stored procedures as clearly it does!
-Mitch
On 11 Sep 2001, Gunnar [iso-8859-1] R�nning wrote: > * Peter Eisentraut <peter_e@gmx.net> wrote: > > | server. PostgreSQL supports both of these things just fine. A whole > | 'nother thing is the ability to return result sets from functions. > | > | OK, other vendors may call the latter for "stored procedures", but that is > | terminological nonsense. And going out there writing an article claiming > | that in PostgreSQL "users do not have the ability to create their own > | stored procedures", without further qualification, is confusing at best. > > > That's not nonsense at all, you can't just go around and redefine the > language used in the database world at your own whims. > > Everybody I know employed in the database arena thinks of a stored procedure > as something that may return result sets. In PostgreSQL it cannot and > does therefore not fit the term stored procedure. Its a limitation, which is currently being worked on. Everywhere _I_ work, stored procedure is just that, a function stored inside the server that does some useful work. > What is confusing is the PostgreSQL use of the term "stored > procedure". To me it sounds like bad marketing, something we really > shouldn't need in the open source world. a) You CAN return result sets already (sort of) by returning a cursor, then doing 'fetch all from cursor'. Its not quite standard, but its possible. b) Soon enough you'll be able to do 'select * from func(args)', half of the code is already written and being committed. Its a question whether I will be able to finish it and get it in 7.2, but at any case, soon this minor limitation will be removed. -ale
As far as I know even Oracle Stored Procedures cannot return result sets,
unless you do some hack using packages...
MSSQL Server can return resultsets, but in a really strange way, I would
say.
Carlos Felipe Zirbes
DBServer Assessoria em Sistemas de Informação
E-mail: carlosz@dbserver.com.br
Fone: (51) 3342-8055
Fax: (51) 3342-4838
-----Original Message-----
From: Mitch Vincent [mailto:mvincent@cablespeed.com]
Sent: Tuesday, September 11, 2001 3:03 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Ridicolus Postgresql review
> That's not nonsense at all, you can't just go around and redefine the
> language used in the database world at your own whims.
"Stored Procedure".. Hmm, that seems to me that the definition of that would
be "a procedure that's stored somewhere". When talking about stored
procedures and databases I would assume that the stored procedure would be
some database procedure (anything you can do with or in a database could be
seen as a procedure, IMHO), that's stored in the said database...
"Stored Procedure" is a very ambiguous term and probably needs to be treated
as such.. Unless there is a written definition somewhere that outlines
exactly how a stored procedure has to return things then I think PG's stored
procedures have the right to carry the name...
> Everybody I know employed in the database arena thinks of a stored
procedure
> as something that may return result sets. In PostgreSQL it cannot and
> does therefore not fit the term stored procedure.
What do they base that on though? The inability to return a record set from
a PG stored procedure is a limitation, no doubt, but not cause to say that
PG doesn't support stored procedures..
> What is confusing is the PostgreSQL use of the term "stored
> procedure". To me it sounds like bad marketing, something we really
> shouldn't need in the open source world.
I think PG is using the term as well as anyone could use such an
ambiguous term.. I think it's fair to list the limitations of PG stored
procedures when discussing feature sets but I don't think it's fair to say
that PG doesn't have stored procedures as clearly it does!
-Mitch
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
* Alex Pilosov <alex@pilosoft.com> wrote: | | b) Soon enough you'll be able to do 'select * from func(args)', half of | the code is already written and being committed. Its a question whether I | will be able to finish it and get it in 7.2, but at any case, soon this | minor limitation will be removed. Cool ! I don't agree it is minor though, as I've encountered organizations using Oracle that has ditched PostgreSQL because of this particular limitation. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
On Tue, 11 Sep 2001, Mitch Vincent wrote: > I think PG is using the term as well as anyone could use such an > ambiguous term.. I think it's fair to list the limitations of PG > stored procedures when discussing feature sets but I don't think it's > fair to say that PG doesn't have stored procedures as clearly it does! Well, the author of the article was an idiot for many reasons. Mainly because he talked about Mysql and Postgres most of the time without differentiating between them, and sometimes mixing up facts between the databases when he *did*. In which case, the article *did* mention that perl, and other languages are available, but not to what database (clearly) and not to what extent; while at the same time saying neither database supports stored procedures. I blame the author. But as far as the comments on this list, the main differentiation between stored procedures and functions (as commonly accepted in the database world) was that stored procedures can return result sets and can be associated in packages, functions do not have this distinction. That said, postgres has functions, not stored procedures. Personally, I wish postgres *did* have stored procedures... I like them far better. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. Thomas INN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830 | | Email: sthomas@townnews.com AIM : trifthen | | Web : hamster.lee.net | | | | "Most of our lives are about proving something, either to | | ourselves or to someone else." | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
It seems that the argument is over what a "stored procedure" is.... So can anyone answer that with something to back it up? Opinions are great and all but I think something more substantial than the "just 'cause" reason is needed here :-) Thanks! -Mitch > I blame the author. > > But as far as the comments on this list, the main differentiation > between stored procedures and functions (as commonly accepted in the > database world) was that stored procedures can return result sets and > can be associated in packages, functions do not have this distinction. > > That said, postgres has functions, not stored procedures. Personally, > I wish postgres *did* have stored procedures... I like them far better. > > -- > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ > | Shaun M. Thomas INN Database Programmer | > | Phone: (309) 743-0812 Fax : (309) 743-0830 | > | Email: sthomas@townnews.com AIM : trifthen | > | Web : hamster.lee.net | > | | > | "Most of our lives are about proving something, either to | > | ourselves or to someone else." | > | -- Anonymous | > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ > >
----- Original Message ----- From: "Mitch Vincent" <mvincent@cablespeed.com> Subject: Re: [GENERAL] Ridicolus Postgresql review > It seems that the argument is over what a "stored procedure" is.... So can > anyone answer that with something to back it up? Opinions are great and all > but I think something more substantial than the "just 'cause" reason is > needed here :-) > > Thanks! > > -Mitch > So .. I'll give it a try. I'll leave the discussion to you. (Because PostgreSQL does actually support, what I think, a stored procedure should be) This is, what Oracle says on stored procedures (in Oracle8i Application Developer's Guide - Fundamentals Release 8.1.5) ################################################################## Stored Program Units (Procedures, Functions, and Packages) A stored procedure, function, or package is a PL/SQL program unit that has the following features: - Has a name. - Can take parameters, and can return values. - Is stored in the data dictionary. - Can be called by many users. ---------------------------------------------------------------------------- ---- Note: The term stored procedure is sometimes used generically to cover both stored procedures and stored functions. The only difference between procedures and functions is that functions always return a single value to the caller, while procedures do not return a value to the caller. ---------------------------------------------------------------------------- ---- ################################################################## So a stored procedure in Oracle can return values. I can't see, if this implies, that a set of results can be returned. Here is, what IBM (DB2) says about stored procedures (from stored procedures information site ... found on www) ################################################################## First, in a nutshell, what is a stored procedure? A stored procedure is an application program that is executed by DB2 for OS/390 in response to a single SQL CALL statement. It can contain SQL statements, as well as any application or business logic. A stored procedure can be written in one of many high level languages, such as C, C++, COBOL, PL/I, S/390 Assembler, and with recent maintenance, in REXX, procedural SQL ,and soon in Java. Support for invoking a stored procedure and processing its result sets is built into many client applications, and also into ODBC, JDBC and SQLJ standards. ################################################################## IBM clearly claims, that a stored procedure (in DB2) can return result sets. Now let's have a look at MS SQL-Server (from the MS-Website, MSDN Home > MSDN Library > Microsoft SQL Server > Stored Procedures) ################################################################## Stored procedures in SQL Server are similar to procedures in other programming languages in that they can: - Accept input parameters and return multiple values in the form of output parameters to the calling procedure or batch. - Contain programming statements that perform operations in the database, including calling other procedures. - Return a status value to a calling procedure or batch to indicate success or failure (and the reason for failure). You can use the Transact-SQL EXECUTE statement to run a stored procedure. Stored procedures are different from functions in that they do not return values in place of their names and they cannot be used directly in an expression. ################################################################## From this definition I can't see, if a stored procedure can return a result set. And last (maybe least) the definition of stored procedures at webopedia.internet.com (I know .. I'll be flamed for posting that ;-): ################################################################## In database management systems (DBMSs), an operation that is stored with the database server. Typically, stored procedures are written in SQL. They're especially important for client-server database systems because storing the procedure on the server side means that it is available to all clients. And when the procedure is modified, all clients automatically get the new version. ################################################################## There is no word on returning values at all.
Hey guys,
Does anyone know anything about this SQL*Net compatible thing which we
are supposed to be developing according to the article?
I haven't heard anything about it.
Also, it says we are planning full Unicode support for the future.
Don't we already have unicode support? (not sure I'm not experienced
with multi-byte encodings at present).
Presently I'm writing an email to David Stodder, their Editorial
Director, asking him to remove that article until they fix the
inaccuracies.
So far the mistakes I have are :
- "Both MySQL and PostgreSQL are multithreaded servers..."
PostgreSQL is NOT a multi-threaded server. It is *no-where* claimed to
be a multi-threaded server.
- "PostgreSQL provides support for queries and data manipulation
statements that span multiple database instances."
PostgreSQL does NOT support queries and data manipulation statements
spanning multiple database instances. This is well known, and for the
author to even somehow get the concept that PostgreSQL DOES do this,
demonstrates his absolute LACK of even the most basic knowledge
regarding PostgreSQL.
- "...subqueries are at the top of that list along with support for
hierarchical queries..."
PostgreSQL fully supports subqueries and has done so for many releases.
- "PostgreSQL plans to release a SQL*Net compatible service that will
make a PostgreSQL database look to outside applications like an Oracle
server."
This is not the case.
- "The upcoming release of the Red Hat Inc. database packages PostgreSQL
7.1.2 with Red Hat Linux 7.1, integrated under a single installation
mechanism."
It's not upcoming. It's been available for around a month now.
Regards and best wishes,
Justin Clift
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Justin Clift wrote: > So far the mistakes I have are : > > - "Both MySQL and PostgreSQL are multithreaded > servers..." > > PostgreSQL is NOT a multi-threaded server. It > is *no-where* claimed to be a multi-threaded > server. Hm... maybe you should clarify that this doesn't mean that a PostgreSQL server is restricted to only handle one request at a time? This email, its content and any attachments is PRIVATE AND CONFIDENTIAL to TANDBERG Television. If received in error please notify the sender and destroy the original message and attachments.
On Wed, 12 Sep 2001, Justin Clift wrote:
> Hey guys,
>
> Does anyone know anything about this SQL*Net compatible thing which we
> are supposed to be developing according to the article?
Haven't read the article but from my Oracle days SQL*Net is the thingy
that lets you connect to multiple instances/databases from one
session(?).
In fact if memory servers me correct it allows RI based on tables on
a remote server. There was a command that allowed you to create a
database connection in the current 'instance' to other instances or
remote databases.
Cheers,
Rod
--
A small clue and no money
will get you further than
lots of money and no clue.
> Hey guys, > > Does anyone know anything about this SQL*Net compatible thing which we > are supposed to be developing according to the article? > > I haven't heard anything about it. It is on our TODO list. That's as far as it has gone. > Also, it says we are planning full Unicode support for the future. > Don't we already have unicode support? (not sure I'm not experienced > with multi-byte encodings at present). Yes, have had it for many releases, but is a configure flag. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Thanks Bruce, I'll check the Archives for more info about it then. Prob should have done that before asking. :-) Regards and best wishes, Justin Clift Bruce Momjian wrote: > > > Hey guys, > > > > Does anyone know anything about this SQL*Net compatible thing which we > > are supposed to be developing according to the article? > > > > I haven't heard anything about it. > > It is on our TODO list. That's as far as it has gone. > > > Also, it says we are planning full Unicode support for the future. > > Don't we already have unicode support? (not sure I'm not experienced > > with multi-byte encodings at present). > > Yes, have had it for many releases, but is a configure flag. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Well having worked on both SQL Server and Oracle (although not the latest version of oracle) let me clear the air on thedifferences between the two as far as stored procs are concerned. On SQL Server you can return many result sets. On Oracle, you can't. The best thing you can do is return arrays as parameters and simulate a result set by populating thatarray row by row (SLOW). I think in most situations, you'll see people just running a select statement from the clientside whenever possible. I much prefer working in Sybase and SQL Server because of the ability to return multiple result sets. Roy.
You are making a confusion here.
To be able to access remote servers in Oracle you use a DB-LINK, not a
SQL*Net (wich is just used to make a single, normal connection to an Oracle
Server).
Carlos Felipe Zirbes
DBServer Assessoria em Sistemas de Informação
E-mail: carlosz@dbserver.com.br
Fone: (51) 3342-8055
Fax: (51) 3342-4838
-----Original Message-----
From: Roderick A. Anderson [mailto:raanders@tincan.org]
Sent: Wednesday, September 12, 2001 11:36 AM
To: Justin Clift
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Ridicolus Postgresql review
On Wed, 12 Sep 2001, Justin Clift wrote:
> Hey guys,
>
> Does anyone know anything about this SQL*Net compatible thing which we
> are supposed to be developing according to the article?
Haven't read the article but from my Oracle days SQL*Net is the thingy
that lets you connect to multiple instances/databases from one
session(?).
In fact if memory servers me correct it allows RI based on tables on
a remote server. There was a command that allowed you to create a
database connection in the current 'instance' to other instances or
remote databases.
Cheers,
Rod
--
A small clue and no money
will get you further than
lots of money and no clue.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Andrea Aime wrote: > If you want to get angry, take a look at: > http://www.iemagazine.com/010918/414feat3_1.shtml Seems that the article has been removed. I've sent a note to the editor, and he replied by asking if I wanted it published in the print edition, which I think will happen. -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
Hi all, This article was removed because it has so many inaccuracies (I asked their Editorial Director to remove it until they were fixed). They asked me yesterday to provide them with some more feedback, and to prove that the things which are wrong, are wrong. I'll probably answer it sometime tomorrow (that would be in about 12-14 hours time now). Regards and best wishes, Justin Clift Alessio Bragadini wrote: > > Andrea Aime wrote: > > > If you want to get angry, take a look at: > > http://www.iemagazine.com/010918/414feat3_1.shtml > > Seems that the article has been removed. I've sent a note to the editor, > and he replied by asking if I wanted it published in the print edition, > which I think will happen. > > -- > Alessio F. Bragadini alessio@albourne.com > APL Financial Services http://village.albourne.com > Nicosia, Cyprus phone: +357-2-755750 > > "It is more complicated than you think" > -- The Eighth Networking Truth from RFC 1925 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi