The problem is not adding the features, it is figuring out the API for offering them, and seeing the need.

Which of the above user-defined features does DBD::AnyData need? All of them? Some? We probably should offline a discussion of how to provide them in a sane manner.

Some are already present in some form. For instance Text::xSV offers the ability to pre-filter input as it comes in. There is nothing to stop such a filter from saying, "These characters are not allowed." That won't work for eliminating embedded tabs in tab-delimited data. But it would for NUL characters. And if you want to disallow tabs embedded in a tab-delimited file, you could just wrap Text::xSV with the necessary validation logic.

Also as dragonchild points out, it reads based on $/ which can effectively allow you to change the record separator. Furthermore because I got tired of bug reports about invalid csv files, by default Text::xSV will treat either \n or \r\n as a newline, so files produced on Windows can be read on Unix and vice versa.

Some of the other missing features can't presently be worked around. For me the barrier isn't adding them if I thought people would use them, it is figuring out what a reasonable API should be.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.