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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDcx/nIB7bNG8LQkwRAl1GAJkB5akE6fWyVSrEWV6Th/tGIqnr1QCdHQXK
YdWF31ex3j4TEYfPdsFwTZ0=
=I2VZ
-----END PGP SIGNATURE-----

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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,


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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.



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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.
>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq