Thread: PL language selection

PL language selection

From
Nicolay A Vasiliev
Date:
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

Re: PL language selection

From
Martijn van Oosterhout
Date:
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

Re: PL language selection

From
Richard Huxton
Date:
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

Re: PL language selection

From
Nicolay A Vasiliev
Date:
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,

Re: PL language selection

From
Nicolay A Vasiliev
Date:
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

Re: PL language selection

From
Tino Wildenhain
Date:
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.



Re: PL language selection

From
Nicolay A Vasiliev
Date:
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.
>