[Libpqxx-general] operator== for fields

[Carlos Moreno]

Hi,

I'm a new libpqxx user --- for the longest time I've been using
the old libpq++, with all its problems and limitations, but it
has done the job for me, and I've been reluctant to mess with
perfectly functional production code.

One of the things that most annoys me from libpq++ is its lack of
compatibility with std::string, and that's one of my big positive
first impressions about libpqxx.

However, on this token I do have one complaint that you must be
already guessing from the subject line.

I would probably go as far as to suggest that class result::field
should have implicit conversion to std::string --- as much as
implicit conversion operators are widely seen as an almost
unconditionally bad idea, I feel that in this case, result::field
should almost be a typedef for std::string  (of course, that would
mean sacrificing a lot of interesting functionality, so it is good
as it is, being a class of its own).

But intuitively, the data that we get from a database is a string;
in the docs, I see some discussion about the issues of "intuition"
often telling us that things would behave as they behave in the
SQL realm  (since after all, what we're getting is a representation
of data that lives in the database).

But still, I think it is a universally accepted principle that
data that we read on a client application is data received in the
form of strings --- our client application provides any extra logic
to give that data the required meaning  (thus the conversion
member-functions)

Ok, but even if we do not go for the implicit conversion to
std::string, I think at the very least, class result::field should
allow us to directly compare with an std::string.  The following
construct is the most normal (and most intuitive) thing to do in
client applications, IMHO:

    if (db[row]["username"] == "admin")

or

    const string reserved = "xxx";
    if (db[row]["whatever"] != reserved)


I agree with the analysis in the documentation that the usefulness
of operator== to compare two field objects is questionable (two
different fields correspond to different data --- why would we
compare them??  If anything, we would compare them in the SQL
realm, in the cases where it does make sense).  Or what the hell,
in the rare occasions where we need to compare them, then we do
go out of our way and convert them to the right type (or string
as the general case) and then compare.

Also, in case we go for the idea that implicit conversion to
std::string is not a good idea  (or that the benefits do not
compensate for the problems that we know implicit conversions
suffer from), I would suggest to make std::string a first-class
citizen (as const char * is) and provide a member function str()
in addition to --- or rather, *instead* --- c_str().

If we need a C-style string (which, really, why would we!! :-)),
then we could still use field.str().c_str().

I mean, it makes sense to me that since we're using C++, it
should be natural to use the C++ idioms and being forced to go
out of our way when we need to use the C idioms, rather than
things like the following, a situation where the C idiom is
the natural one and favored by the library, and we have to
get out of our way to do it with the C++ idiom:

    if (db[row]["username"].c_str() != std::string(""))

(sure, I could do db[row]["username"].as<std::string>() != "",
which would defeat my latest argument, but still goes with
my argument that comparison to std::string should be transparent)

And yes, I know I could provide --- for my own use and without even
having to patch the library's source code --- a quick fix,
doing:

bool operator== (const pqxx::result::field & f, const std::string & s)
{
    return f.as<std::string>() == s;
}

inline bool operator== (const std::string & s, const pqxx::result::field 
& f)
{
    return f == s;
}

And same for the two operator!= ...  But still...


I hope I'm not getting into some "long debated and agreed upon"
issues --- the list archives don't seem to go too far back, and
I didn't find anything on this subject.

Thanks,

Carlos
--