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

[ssleert]

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

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

[tt4g]

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)

[ssleert]

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]

why we doesnt have standard string trait for such cases?

[jtv]

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]

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.)

[jtv]

I don't know why I never mentioned this in here before... We do now have support for reading arrays, but as a separate field member function: as_sql_array(). This parses an SQL array (you do have to know the number of dimensions beforehand), and returns a pqxx::array containing the data. It's a massive improvement over the old array_parser API.

It's still not quite the same as supporting the regular conversion system that we have for other types, but I hope it covers most use-cases. There's a bunch of work to be done before I want to dive into that: first I want to simplify the plethora of "exec" functions we have.

So I think we can close this ticket now, actually. It's not perfect, but I think it's pretty good; and there's not much more I think we can do right now.