New release roadmap

14 views
Skip to first unread message

Sergey Prokhorov

unread,
Mar 20, 2018, 10:44:36 AM3/20/18
to Erlang epgsql Postgres driver use and development
Looks like we have enough changes for a new epgsql release?

======
Changelog draft:
  • Make epgsql commands pluggable (TODO: docs).
    Now we are not limited only by API functions provided by epgsql (equery/squery/prepared_query etc), but may create own commands as a plugins. Still, understanding of PostgreSQL network protocol needed to be able to do so.
  • Make epgsql datatype encoding/decdoding pluggable (see https://github.com/epgsql/epgsql/blob/devel/pluggable_types.md).
    Now we are able to add or tweak codecs for existing as well as custom PostgreSQL datatypes (like datetime, varchar, enum, arrays etc).
    XXX: Highly recommend to add `{codecs, []}` option to your epgsql:connect/X calls if you don't use PostGIS and hstore datatypes: this will reduce connection setup time.
  • epgsql internals had a huge refactoring.
    Code now is much more modular, documented and have a lot of internal typespecs. Performance improvements also expected.
  • now we try to use iolists as much as possible and avoid binary and string concatenations when ever possible.
    Expect noticeable performance improvements for large BYTEA / TEXT / VARCHAR / JSON / JSONB etc fields.
  • Extended epgsql:with_transaction/3 (see https://github.com/epgsql/epgsql/blob/devel/src/epgsql.erl#L345-L356).
    Now it's possible to preserve original exception's stacktrace, finally!
    TODO: add to README
  • macaddr and macaddr8 datatypes support added
  • Float datatype support was extended with `nan`, `minus_infinity`, `plus_infinity`
  • elvis code style check was added to our travis pipeline
  • Brand-new PostgreSQL scram-sha-256 auth method added (see https://www.postgresql.org/docs/10/static/auth-methods.html#AUTH-PASSWORD and https://www.postgresql.org/docs/current/static/sasl-authentication.html)
  • A lot of typespecs were rewritten and lots of internal typespecs were added
Incompatibilities:

We tried to maintain API backward-compatibility as much as possible, despite the fact that internals had a huge refactoring. But careful testing is needed before migrating.
  • Some unexpected performance issues may appear, but we expect some performance improvements, especially for a large result sets (when a lot of rows are returned by a query) and for large string/json/blob query parameters
  • epgsql:update_type_cache/2 API was changed, but it wasn't documented
  • A lot of typespecs were updated. Some typespecs were deprecated or moved from epgsql.erl to other modules. So, some new dialyzer warnings might pop-up
  • Some new error messages might be returned, especially from epgsql:connect/X functions
  • Memory consumption per-connection might slightly grow because we maintain per-connection OID<->codec mapping table, which might be quite big in some cases. This also may produce bigger error_logger reports in case of epgsql connection process failures.
  • Some exported .hrl files have been changed. #column{} and #statement{} record definitions were extended.
  • PostGIS users might be affected by cleanup of ewkb.erl and epgsql_geometry.hrl
  • Streaming replication users should pay extra attention. No tests were broken, but a lot of modifications were made to this code.
  • Passing integer / atom / float as a value of a text / varchar / bytea query parameter is now deprecated (so, `epgsql:equery(C, "SELECT $1::text", [my_atom])` will still work but is not recommended)
  • Redshift and CockroachDB users might expirience some problems. Please, report bugs!
  • Of course, some hidden bugs might be introduced
=======

Also, do you think it might make sense to increment version to 4.0.0 instead of 3.5.0? On the one side, epgsql internals were significantly changed, on the other, public APIs haven't been changed much.

David Welton

unread,
Mar 20, 2018, 2:43:56 PM3/20/18
to Sergey Prokhorov, Erlang epgsql Postgres driver use and development
> Also, do you think it might make sense to increment version to 4.0.0 instead
> of 3.5.0? On the one side, epgsql internals were significantly changed, on
> the other, public APIs haven't been changed much.

I think that makes sense - between some typespecs changing and *lots*
of internal changes, it's fair to give it a good bump.

A huge thanks for all your work on this, this is good stuff!

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Sergey Prokhorov

unread,
Apr 12, 2018, 5:19:50 AM4/12/18
to Erlang epgsql Postgres driver use and development
So, here it is!


Thanks for everybody involved!

вторник, 20 марта 2018 г., 19:43:56 UTC+1 пользователь David Welton написал:
Reply all
Reply to author
Forward
0 new messages