Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

String conversion API needs extensions #948

Open
jtv opened this issue Feb 4, 2025 · 1 comment
Open

String conversion API needs extensions #948

jtv opened this issue Feb 4, 2025 · 1 comment
Labels

Comments

@jtv
Copy link
Owner

jtv commented Feb 4, 2025

For the 8.0 release it would be useful to extend the string conversion API with additional parameters:

Obviously though I don't want to break compatibility on the string conversion API on short notice. We'll need a smooth transition process.

Some ideas...

  • We could add a separate API versioning scheme to the string conversions. But it's tedious and ugly and I don't want to maintain a list of API versions. Also, there's a chance that we won't even need the scheme again in the future.
  • Or we could add optional string_traits fields for "these functions accept an encoding" and "these functions accept a source_location" and make them default to false. (If I can't make that work, they could be stand-alone constants). It feels like double specification though.
  • Or we could use nasty template trickery to suss out a conversion function's signature, and figure out which arguments to pass. There's some ad-hockery there (because there are several conversion functions to support), but we already do at least part of this work in pqxx::internal::args_f.

The new parameters would have to have defaults for compatibility. That's not always safe for encodings, but I think it's feasible to enforce this at compile time.

@jtv
Copy link
Owner Author

jtv commented Feb 9, 2025

Looks like it's actually reasonably simple to do:

  1. Use decltype(pqxx::internal::args_f(pqxx::string_traits<T>::function)) to get a tuple representing the parameter types for a member function of pqxx::string_traits<T>.
  2. Extract individual parameter types using std::tuple_element_type<index, params_tuple_type>.
  3. Remove irrelevant qualifications using std::remove_cvref_t<param_type>.
  4. Compare the result to an expected type using std::is_same<stripped_type, expected_type>.

We can then specialise code for different API versions using if constexpr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant