Summary:ASTERISK-23459: [patch]Incorrect check for key field and NULL column values in update_odbc
Reporter:zvision (zvision)Labels:
Date Opened:2014-03-10 17:36:41Date Closed:2014-03-28 12:11:35
Versions:11.8.1 Frequency of
causesASTERISK-23675 [patch] Segmentation Fault on first SIP registration using res_config_odbc
causesASTERISK-23677 [res_odbc] Syntax error in peer registration
is related toASTERISK-23351 [patch]Updating realtime sippeers using res_config_pgsql backend fails when 'port' column is null
Environment:Attachments:( 0) res_config_odbc.diff
Description:The function update_odbc has two small issues:
1. It checks for existence of the first column from the parameter list
   instead of the existence of a key field used in the WHERE clause.
   The error message is correct, just the column used for the check is not.
2. The check for NULL integer column value examines a column name
    instead of a column value for an empty string.

The patch attached corrects both issues and also permits the first column
in the list to take a NULL value.
Comments:By: zvision (zvision) 2014-03-10 17:45:00.226-0500

This issue was triggered by connecting an Asterisk to a PostgreSQL realtime SIP peers via ODBC. When the port column in sipregs (sippeers) table is defined as a nullable integer, during deregistration Asterisk tries to put an empty string into the port column. It would be no problem, if the code worked as expected - but due to these bugs, no NULL is substitued in place of an empty string.
I know this is a general issue, but just wanted to provide a real-world use case for this bug report.

By: Rusty Newton (rnewton) 2014-03-11 18:32:40.065-0500

Thanks! You can go ahead and post your patch on Reviewboard:

[Instructions on Code Review can be found at this link|https://wiki.asterisk.org/wiki/display/AST/Code+Review]

Once you create a reviewboard entry, post the reviewboard link on here. Thanks!

By: zvision (zvision) 2014-03-12 02:44:36.309-0500

Thanks for the info! I have posted the patch on Reviewboard - it can be found [here|https://reviewboard.asterisk.org/r/3335/]

By: Walter Doekes (wdoekes) 2014-03-12 03:58:06.232-0500

Ah, [~jmls] just ran into the same problem with the postgres backend, here ASTERISK-23351.