On 2004.04.29 22:21 Tom Lane wrote:
> "Parameters to a function can be composite types (complete table
> rows). In that case, the corresponding identifier $n will be a row
> variable, and fields can be selected from it, for example
$1.user_id."
That says that a parameter passed *into* a plpgsql f
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> What a drag. The documentation says it supports this.
No it doesn't ...
> "Parameters to a function can be composite types (complete table
> rows). In that case, the corresponding identifier $n will be a row
> variable, and fields can be selected
"Thomas Chille" <[EMAIL PROTECTED]> writes:
> Now I understand that i can not split easily my scripts into logical units but what
> i not understand is the documention not correct
> or is my problem not similiar to the example in point 37.4.3 on
> http://www.postgresql.org/docs/7.4/static/plpgsql
Hello Tom,
thank u for your fast reply!
Now I understand that i can not split easily my scripts into logical units but what i
not understand is the documention not correct
or is my problem not similiar to the example in point 37.4.3 on
http://www.postgresql.org/docs/7.4/static/plpgsql-declarati
> Greetings.
>
> Using pg6.5.1 on Solaris 2.6, I'm trying to create a very simple function
> using plpgsql. Here's the code I've executed:
>
> /*
> CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
> '/opt/pgsql/lib/plpgsql.so' LANGUAGE 'C';
>
> CREATE TRUSTED PROCEDURAL LANGUAGE
edi 3 novembre 1999 07:18
A: [EMAIL PROTECTED]
Objet: [GENERAL] plpgsql problem: relocation error
Greetings.
Using pg6.5.1 on Solaris 2.6, I'm trying to create a very simple function
using plpgsql. Here's the code I've executed:
/*
CREATE FUNCTION plpgsql_call_handler () RETURN
