My opinion would be to support the official standard ( despite the fact I also think it's braindead to have the user 'guess' at the maximum length they might need.) If using a sentinel value (-1) doesn't conflict with any existing practice, I'd say 'extend' the 'standard' in that direction. The alternative would be an install/build time choice of behaviour, which might be useful for ingres-only sites who don't need the 'compatibility' with other drivers. I've always found the DBI to be too low-level to be able to write a RDBMS-agnostic script/app anyway. Don't take that as a criticism of the dbi. I find the dbi to be the most compelling reason outside of the perl core itself for using perl.
Mark. Ingres/Oracle DBA/Developer. -----Original Message----- From: Mike Battersby [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 8:17 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Ignore LongReadLen? (Also DBD::Ingres) Dear DBI developers, I've been doing some more work on the long data type support in DBD::Ingres (which unfortunately still hasn't managed to make it into the official distribution), and now have support for the Ingres byte and long byte binary data types as well. I have a question about long data types though, which hasn't been resolved by checking other DBD drivers, as they all seem to do things differently. Is it preferable to support LongReadLen and LongTruncOk, or just to return the entire field? To be honest, in my own work I never have a need for limiting the length, and it seems ludicrous to make the user guess what the largest size data is if you can just return the whole lot anyway by allocating memory dynamically. Maybe there needs to be a sentinel value (-1?) for LongReadLen to indicate fetching everything? At the moment I have two versions of DBD::Ingres in development, one which supports the Long* settings exactly as per the DBI pod, and one which ignores them entirely and always returns the complete data. Any hints about the correct way to deal with long values would be appreciated. I consider it essential to allow the programmer to fetch all the data without having to guess at the size. Henrik: if you read this and you ever get time to look at my long data type stuff, drop me a line first so I can zap you the most recent version. Cheers, - Mike Battersby -- Mike Battersby <[EMAIL PROTECTED]> The University of Melbourne Fetch my pgp key from: http://ariel.ucs.unimelb.edu.au/~mib/pgpkey.txt ************************************************************************************** This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. It must not be used by, or its contents copied or disclosed to, persons other than the intended recipient. However, the contents of this e-mail may be intercepted, monitored or recorded by Insurance Technology Solutions Limited for the purposes of ensuring compliance with its policies and procedures. Any liability (in negligence or otherwise) arising from any third party acting, or refraining from acting, on any information contained in this e-mail is excluded. If you have received this e-mail by mistake please notify our System Administrators at [EMAIL PROTECTED] and delete this e-mail. It is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. Please carry out such virus and other checks as you consider appropriate. No responsibility is accepted by Insurance Technology Solutions Limited in this regard. **************************************************************************************
