Thread: PL language selection
Hello! I am going to be inspired into PostgreSQL community. So I need your advices, buddies. There are a number of different PL-languages. How do you select these languages? I think PL/SQL is more fast or am I wrong? Suggest me please your way of PL language selection. Thanks in advance, Nicolay
On Thu, Nov 10, 2005 at 12:16:12PM +0300, Nicolay A Vasiliev wrote: > There are a number of different PL-languages. How do you select these > languages? I think PL/SQL is more fast or am I wrong? > > Suggest me please your way of PL language selection. Well, it kind of depends on what you want to do. Different languages are good for different things. If you want pattern matching you might want pl/perl. For simple SQL stuff, pl/sql has the advantage that it can be inlined. pl/pgsql looks similar to oracles offering, some people like that. The languages are all fast enough that you should really consider maintainability, readabilty and coding experience before speed... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
Nicolay A Vasiliev wrote: > Hello! > > I am going to be inspired into PostgreSQL community. So I need your > advices, buddies. Crikey! I must be more persuasive than I thought :-) > There are a number of different PL-languages. How do you select these > languages? I think PL/SQL is more fast or am I wrong? Hmm - it varies. You are guaranteed to always have plpgsql available wherever PG is installed. It's not very good at dynamic stuff - with Perl/TCL etc you can write one trigger function and have it adapt itself to different tables quite easily. The others have their strengths and weaknesses depending on the language itself. If you're prepared to compile from source there is a pl-php which might interest you. It's from the nice people at Command Prompt: http://www.commandprompt.com/community/plphp/ -- Richard Huxton Archonet Ltd
Martijn van Oosterhout wrote: > On Thu, Nov 10, 2005 at 12:16:12PM +0300, Nicolay A Vasiliev wrote: > >>There are a number of different PL-languages. How do you select these >>languages? I think PL/SQL is more fast or am I wrong? >> >>Suggest me please your way of PL language selection. > > > Well, it kind of depends on what you want to do. Different languages > are good for different things. If you want pattern matching you might > want pl/perl. Oh, great! It sounds good cause we use Perl hardly in our work and understand something in this language :). > For simple SQL stuff, pl/sql has the advantage that it > can be inlined. pl/pgsql looks similar to oracles offering, some people > like that. I thought the same. When I worked with Sybase Adaptive SQL Anywhere few years ago I liked its Watcom SQL dialect for its power of computation possibilities. > > The languages are all fast enough that you should really consider > maintainability, readabilty and coding experience before speed... This is very important especially in case of active using of database in insert/update conditions. And I thought PL/SQL is more "native". If they are equally by maintainability - so, PosgreSQL is fine a lot :). Regards,
Richard Huxton wrote: > Nicolay A Vasiliev wrote: > >> Hello! >> >> I am going to be inspired into PostgreSQL community. So I need your >> advices, buddies. > > > Crikey! I must be more persuasive than I thought :-) Wow :) > >> There are a number of different PL-languages. How do you select these >> languages? I think PL/SQL is more fast or am I wrong? > > > Hmm - it varies. You are guaranteed to always have plpgsql available > wherever PG is installed. It's not very good at dynamic stuff What do you mean? > - with Perl/TCL etc you can write one trigger function and have it adapt itself > to different tables quite easily. Perl is our working horse :), so this sounds good. > > The others have their strengths and weaknesses depending on the language > itself. If you're prepared to compile from source there is a pl-php > which might interest you. > > It's from the nice people at Command Prompt: > http://www.commandprompt.com/community/plphp/ I've heard about this, but Perl and Python are more preferred for us. Regards, Nicolay
Nicolay A Vasiliev schrieb: > Richard Huxton wrote: > >> Nicolay A Vasiliev wrote: >> ... >> The others have their strengths and weaknesses depending on the >> language itself. If you're prepared to compile from source there is a >> pl-php which might interest you. >> >> It's from the nice people at Command Prompt: >> http://www.commandprompt.com/community/plphp/ > > > I've heard about this, but Perl and Python are more preferred for us. ^^^^^^^ as such, dont miss http://python.projects.postgresql.org/ which is a new approach for pl/python (among other things it does too) It allows you, with PG 8.x, to write set returning functions which are lazy (e.g. built values as they are fetched) - via standard generator objects.
Thanks! Nice link! Tino Wildenhain wrote: > as such, dont miss > http://python.projects.postgresql.org/ > > which is a new approach for pl/python (among > other things it does too) It allows you, > with PG 8.x, to write set returning functions > which are lazy (e.g. built values as they > are fetched) - via standard generator objects. >