Jason Godden wrote:
> Hi Sean,
>
> Yeah - It is declared VOLATILE. I think there must be something specific with
> the way PL/PGSQL handles child processes of a called function. The child
> process actually spawns mpg123 or ogg123 so it has to live beyond the life of
> the parent. Not sure. What I might do is rewrite the entire procedure from
> woe to go in using SPI and see how that goes. Failing that I guess I could
> always peek at the source! : )
PL/pgSQL does not pay any attention or could affect child processes of a
backend to my knowledge. Are you sure that the PL/pgSQL function really
calls your C function forking off the child? The best way to check would
be to have some NOTICE coming out of your C function before it actually
does create the child.
Jan
>
> Thanks,
>
> Jason
>
> On Mon, 18 Aug 2003 04:48 am, Sean Chittenden wrote:
>> > Problem is that when I call these particular functions from within
>> > plpgsql rather than through a single sql command the child never
>> > actually starts (or starts and then exits immediately).
>>
>> Are you sure? I can't think of much that'd prevent a C function from
>> executing other than how you've declared the function (ie, is PgSQL
>> caching the results of the function?). Make sure you've declared it
>> as VOLATILE (or don't declare it anything and it'll default to
>> VOLATILE).
>>
>> http://developer.postgresql.org/docs/postgres/sql-createfunction.html
>>
>> -sc
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
