Thread: Iis there anyway to do this(see in message)

Iis there anyway to do this(see in message)

From
Tony Caduto
Date:
Hi,
Just wondering if there is a way to monitor the SQL that is executed
inside a PL/pgsql function?
I can see some SQL via the stats view, but it does not show the sql that
is being executed in a function.
The reason I ask is it would make debugging large complex functions much
easier.
I get a lot of requests from former MS SQL server DBAs/developers for
such capablility.

Thanks,

Tony Caduto
http://www.amsoftwaredesign.com


Re: Iis there anyway to do this(see in message)

From
Michael Fuhr
Date:
On Sun, Jan 16, 2005 at 07:00:42PM -0600, Tony Caduto wrote:

> Just wondering if there is a way to monitor the SQL that is executed
> inside a PL/pgsql function?
> I can see some SQL via the stats view, but it does not show the sql that
> is being executed in a function.

You can get some logging with the log_statement and debug_*
configuration settings, although maybe not as much as you'd like.

http://www.postgresql.org/docs/7.4/static/runtime-config.html#RUNTIME-CONFIG-LOGGING-WHAT

> The reason I ask is it would make debugging large complex functions much
> easier.
> I get a lot of requests from former MS SQL server DBAs/developers for
> such capablility.

People request a trace feature for PL/pgSQL from time to time but
I don't think anybody has implemented it yet.  I'm sure a patch
would be welcome....

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Re: Iis there anyway to do this(see in message)

From
Madison Kelly
Date:
Tony Caduto wrote:
> Hi,
> Just wondering if there is a way to monitor the SQL that is executed
> inside a PL/pgsql function?
> I can see some SQL via the stats view, but it does not show the sql that
> is being executed in a function.
> The reason I ask is it would make debugging large complex functions much
> easier.
> I get a lot of requests from former MS SQL server DBAs/developers for
> such capablility.
>
> Thanks,
>
> Tony Caduto
> http://www.amsoftwaredesign.com

   I am not sure if this is what you mean but this is what I do to see
what DB calls are being made. I add a print statement just before the
actual SQL call (which I actually print to the filehandle 'LOG' which
points to a log file). For example:

$db_update=$DB->prepare("UPDATE file_info SET file_size=?, file_perm=?,
file_acc_time=?, file_mod_time=?, file_user_uid=?, file_user_name=?,
file_group_uid=?, file_group_name=? WHERE file_parent_dir=? AND
file_name=? AND file_type=?") || die...

...

if ( $log_level >= 4 ) { print LOG " |- ".__LINE__." DBI: UPDATE
file_info_".$dev_id." SET file_size=$size, file_perm=$mode,
file_acc_time=$atime, file_mod_time=$mtime, file_user_uid=$uid,
file_user_name=$user, file_group_uid=$gid, file_group_name=$group WHERE
file_parent_dir='/' AND file_name='.' AND file_type='d';\n"; }
        $db_update->execute($size, $mode, $atime, $mtime, $uid, $user, $gid,
$group, "/", ".", "d") || die...

   Noting of course that the quoting might be slightly off because a
prepared statement automatically quotes values as needed. If you wanted
to be really carefully you could quote the values for your log like so:

if ( $log_level >= 4 )
{
    $db_user=$DB->quote($user);
    $db_group=$DB->quote($group);
    print LOG " |- ".__LINE__." DBI: UPDATE file_info SET file_size=$size,
file_perm=$mode, file_acc_time=$atime, file_mod_time=$mtime,
file_user_uid=$uid, file_user_name=$db_user, file_group_uid=$gid,
file_group_name=$db_group WHERE file_parent_dir='/' AND file_name='.'
AND file_type='d';\n";
}

   I hope this was along the lines of your question.

Madison

Re: Iis there anyway to do this(see in message)

From
Tony Caduto
Date:
Michael,
Thank you for the info, it actually should give me enough detail, though
not as convienent as a trace tool would be.

>
>People request a trace feature for PL/pgSQL from time to time but
>I don't think anybody has implemented it yet.  I'm sure a patch
>would be welcome....
>
>
>
Would love to help here, but I am a Pascal guy :-)  I don't think I can
submit a patch in Pascal :-(

Thanks agian,

Tony Caduto