The relative stability of different procedural languages

Started by BigSmokeover 19 years ago7 messagesgeneral
Jump to latest
#1BigSmoke
bigsmoke@gmail.com

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.

However, I've been unable to find any useful information on the
stability of each particular procedural language. I've seen suggestions
for creating a PL comparison matrix, but, short of such a matrix, I
couldn't even find essential information regarding the vitality and
stability of the various PLs.

I'm comfortable with both Ruby and Perl, but wouldn't mind brushing up
a bit on my Python. I'm also comfortable with PHP but have to say that
the idea of running it within Postgres doesn't appeal to me very much.

So, how to the different procedural languages stack up against each
other in terms of stability? After all, adding a language that could
cause random segfaults or huge memory leaks is simply not an option for
a production DB.

#2Merlin Moncure
mmoncure@gmail.com
In reply to: BigSmoke (#1)
Re: The relative stability of different procedural languages

On 7 Dec 2006 14:02:53 -0800, BigSmoke <bigsmoke@gmail.com> wrote:

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.

could you clarify what you are trying to do and why pl/pgsql cant do it?

merlin

#3Joshua D. Drake
jd@commandprompt.com
In reply to: BigSmoke (#1)
Re: The relative stability of different procedural

On Thu, 2006-12-07 at 14:02 -0800, BigSmoke wrote:

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.

PLPerl. And I say this as someone who doesn't even like Perl.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

#4BigSmoke
bigsmoke@gmail.com
In reply to: Merlin Moncure (#2)
Re: The relative stability of different procedural languages

On Dec 7, 11:07 pm, mmonc...@gmail.com ("Merlin Moncure") wrote:

On 7 Dec 2006 14:02:53 -0800, BigSmoke <bigsm...@gmail.com> wrote:

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.

could you clarify what you are trying to do and why pl/pgsql cant do it?

I'm dealing with a trigger function which needs to check the nullness
of a column in 'new' and 'old'. The catch is that the trigger function
needs to take the name of that column as an argument. (I've tried a
kludge which stores 'new' and 'old' in a temporary table, but this
kludge seems too unreliable to trust.)

- Rowan

#5BigSmoke
bigsmoke@gmail.com
In reply to: Joshua D. Drake (#3)
Re: The relative stability of different procedural

On Dec 7, 11:11 pm, j...@commandprompt.com ("Joshua D. Drake") wrote:

On Thu, 2006-12-07 at 14:02 -0800, BigSmoke wrote:

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.PLPerl. And I say this as someone who doesn't even like Perl.

Joshua D. Drake

Thanks heaps! That's the answer I was looking for.

- Rowan

#6Tony Caduto
tony_caduto@amsoftwaredesign.com
In reply to: BigSmoke (#4)
Re: The relative stability of different procedural languages

BigSmoke wrote:

On Dec 7, 11:07 pm, mmonc...@gmail.com ("Merlin Moncure") wrote:

On 7 Dec 2006 14:02:53 -0800, BigSmoke <bigsm...@gmail.com> wrote:

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.

could you clarify what you are trying to do and why pl/pgsql cant do it?

I'm dealing with a trigger function which needs to check the nullness
of a column in 'new' and 'old'. The catch is that the trigger function
needs to take the name of that column as an argument. (I've tried a
kludge which stores 'new' and 'old' in a temporary table, but this
kludge seems too unreliable to trust.)

Why can't you just use something like this:

IF new.yourcolumnname IS NULL THEN

END IF;

I test for null in PLpgsql all the time.

Am I missing something?

Later,

Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration

#7BigSmoke
bigsmoke@gmail.com
In reply to: Tony Caduto (#6)
Re: The relative stability of different procedural languages

On Dec 7, 11:42 pm, tony_cad...@amsoftwaredesign.com (Tony Caduto)
wrote:

BigSmoke wrote:

On Dec 7, 11:07 pm, mmonc...@gmail.com ("Merlin Moncure") wrote:

On 7 Dec 2006 14:02:53 -0800, BigSmoke <bigsm...@gmail.com> wrote:

I'm facing a particular task for which I need any procedural language
but PL/PgSQL. I can't use PL/PgSQL because it doesn't allow me to use
local variables such as new and old from a dynamic command.

could you clarify what you are trying to do and why pl/pgsql cant do it?

I'm dealing with a trigger function which needs to check the nullness
of a column in 'new' and 'old'. The catch is that the trigger function
needs to take the name of that column as an argument. (I've tried a
kludge which stores 'new' and 'old' in a temporary table, but this
kludge seems too unreliable to trust.)Why can't you just use something like this:

IF new.yourcolumnname IS NULL THEN

END IF;

I test for null in PLpgsql all the time.

Am I missing something?

Yes, you're missing something. ;-) Your example doesn't work in my case
where mycolumnname is in argument that is passed to the function.

- Rowan