Postgrex v0.14.0 Postgrex.Types View Source

Encodes and decodes between Postgres’ protocol and Elixir values.

Link to this section Summary

Types

Postgres internal identifier that maps to a type. See http://www.postgresql.org/docs/9.4/static/datatype-oid.html

State used by the encoder/decoder functions

Term used to describe type information

Functions

Defines a type module with custom extensions and options

Link to this section Types

Postgres internal identifier that maps to a type. See http://www.postgresql.org/docs/9.4/static/datatype-oid.html.

State used by the encoder/decoder functions

Term used to describe type information

Link to this section Functions

Link to this function define(module, extensions, opts \\ []) View Source

Defines a type module with custom extensions and options.

Postgrex.Types.define/3 must be called on its own file, outside of any module and function, as it only needs to be defined once during compilation.

Type modules are given to Postgrex on start_link via the :types option and are used to control how Postgrex encodes and decodes data coming from Postgrex.

For example, to define a new type module with a custom extension called MyExtension while also changing Postgrex’s default behaviour regarding binary decoding, you may create a new file called “lib/my_app/postgrex_types.ex” with the following:

Postgrex.Types.define(MyApp.PostgrexTypes, [MyExtension], [decode_binary: :reference])

The line above will define a new module, called MyApp.PostgrexTypes which can be passed as :types when starting Postgrex. The type module works by rewriting and inlining the extensions’ encode and decode expressions in an optimal fashion for postgrex to encode parameters and decode multiple rows at a time.

Extensions

Extensions is a list of Postgrex.Extension modules or a 2-tuple containing the module and a keyword list. The keyword, defaulting to [], will be passed to the modules init/1 callback.

Extensions at the front of the list will take priority over later extensions when the matching/1 callback returns have conflicting matches. If an extension is not provided for a type then Postgrex will fallback to default encoding/decoding methods where possible. All extensions that ship as part of Postgrex are included out of the box.

See Postgrex.Extension for more information on extensions.

Options

  • :null - The atom to use as a stand in for postgres’ NULL in encoding and decoding. The module attribute @null is registered with the value so that extension can access the value if desired (default: nil);

  • :decode_binary - Either :copy to copy binary values when decoding with default extensions that return binaries or :reference to use a reference counted binary of the binary received from the socket. Referencing a potentially larger binary can be more efficient if the binary value is going to be garbaged collected soon because a copy is avoided. However the larger binary can not be garbage collected until all references are garbage collected (default: :copy);

  • :json - The JSON module to encode and decode JSON binaries, calls module.encode_to_iodata!/1 to encode and module.decode!/1 to decode. If nil then no default JSON handling (default: Application.get_env(:postgrex, :json_library, Jason));

  • :bin_opt_info - Either true to enable binary optimisation information, or false to disable, for more information see Kernel.SpecialForms.<<>>/1 in Elixir (default: false);

  • :debug_defaults - Generate debug information when building default extensions so they point to the proper source. Enabling such option will increase the time to compile the type module (default: false);