Re: Allowing for schema.table format in SQL::Statement

On Wed, Nov 23, 2011 at 09:34:06AM +0100, Jens Rehsack wrote:
> 2011/11/22 Brendan Byrd <[email protected]>:
> > (Adding dbi-dev to conversation for
> > https://rt.cpan.org/Ticket/Display.html?id=72588)
> >
> > Still debugging DBD::SNMP right now, and I'm currently fighting with
> > SQL::Statement to allow for schema.table formats. The idea would that it
> > would be possible to reference the MIB name within the table, like
> > IF_MIB.ifTable for IF-MIB::ifTable. However, I'm finding all kinds of code
> > that strips the schema from the table name.
> 
> As far as I know, snmp tables doesn't have a scheme - they might (or might not)
> have a unique dot separated identifier path.
> 
> Let's take dskTable as example. It's full qualified oid is ".1.3.6.1.4.1.2021.9"
> or "enterprises.ucd.9" yada-yada-yada.
> 
> How do you expect the schema.table support can help you and how it is
> required to be changed from current implementation (see DBD::File how
> currently it's used).
> 
> Another example is smProcessStatus - or "enterprises.smart-snmpd.10.7"
> which has it's table at smProcessTable.1 or "1.3.6.1.4.1.36539.10.7.7.1".
> Or smDiskIoStatus (enterprises.smart-snmpd.20.1), which contains two
> tables: smDiskIoTable and smDiskIoIntervalTable.

Perhaps quote the schema indentifier to enable embedded periods:

    SELECT * FROM "enterprises.smart-snmpd.20.1".smDiskIoTable

Tim [who is happy to know almost nothing about snmp]