search

jtv / libpqxx

The official C++ client API for PostgreSQL.
http://pqxx.org/pqxx/
BSD 3-Clause "New" or "Revised" License
976 stars 232 forks source link

Conversion of TEXT[] to std::vector<std::string>. #818

Open ssleert opened 3 months ago

ssleert commented 3 months ago

How i can convert TEXT[] column to std::vector in prepared statements?

I can insert it with prepared statements but i cant get it through prepared statements. Why?

tt4g commented 3 months ago

There is no conversion from array to std::vector. It must be parsed using pqxx::array_parser. See the test code for usage: https://github.com/jtv/libpqxx/blob/7.9.0/test/unit/test_array.cxx

i cant get it through prepared statements. Why?

See this comment: https://github.com/jtv/libpqxx/issues/769#issuecomment-1859205373

ssleert commented 3 months ago

There is no conversion from array to std::vector. It must be parsed using pqxx::array_parser. See the test code for usage: https://github.com/jtv/libpqxx/blob/7.9.0/test/unit/test_array.cxx

i cant get it through prepared statements. Why?

See this comment: #769 (comment)

thx)

ssleert commented 3 months ago

why we doesnt have standard string trait for such cases?

jtv commented 2 months ago

One annoying problem is that the string conversion API does not have a way to pass the prevailing client encoding. For all the other data types, the encoding is irrelevant — if it's strings, we pass them on unchanged, and for the other data types it's effectively always ASCII. Just for arrays it's different. :-(

jtv commented 1 month ago

For #841 I intend to make encodings a "thing" in the libpqxx API. That may provide one small step for this.

There's another issue though that we haven't touched upon: separators. Each type on the SQL side may set its own separator between elements! Usually it's a comma, but at least one standard type uses a semicolon, and there may be others.

This is not hard to support — the pqxx::array class already does it. But is it worth working into the string conversion API? I think it would be possible to extend pqxx::to_string() etc. with an arbitrary parameter pack, which they would pass through straight to the pqxx::string_traits specialisation that they would use. That way it would become possible to extend string conversions with arbitrary extra parameters, such as which separator to use.

But there is a downside to that. Once we go that way, it would become effectively impossible to extend the string conversion API with more template parameters in the future. For example, at some point we might want to implement binary data transfers by adding a "format" parameter. That would then become a source-incompatible API change.

So for now, I think the best thing to do is to deprecate pqxx::field::as_array(), add a member function template to create a pqxx::array out of the field, and plan to rename that one as_array() in the future.

(We could be bold and just immediately create a separate template<…> array<…> as_array() to live side by side with the existing array_parser as_array(). But it would be highly confusing, so let's leave that for a later stage as a hack for backwards compatibility.)