Thread: The relative stability of different procedural languages

The relative stability of different procedural languages

From
"BigSmoke"
Date:
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.


Re: The relative stability of different procedural languages

From
"Merlin Moncure"
Date:
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

Re: The relative stability of different procedural

From
"Joshua D. Drake"
Date:
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




Re: The relative stability of different procedural languages

From
"BigSmoke"
Date:
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


Re: The relative stability of different procedural

From
"BigSmoke"
Date:
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


Re: The relative stability of different procedural languages

From
Tony Caduto
Date:
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


Re: The relative stability of different procedural languages

From
"BigSmoke"
Date:
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