target-postgres

Singer Target for PostgreSQL databases.

Built with the Meltano SDK for Singer Taps and Targets.

Capabilities

• about
• stream-maps
• schema-flattening
• validate-records
• target-schema
• hard-delete

Settings

A full list of supported settings and capabilities is available by running: target-postgres --about

Built-in Settings

The following settings are automatically supported by the Meltano SDK and inherited by this target.

Note on generating fake data

If you need access to the faker instance in your stream map expressions, you will need to install it as an additional dependency in your plugin.

If you're using Meltano, you can add the faker extra to your meltano.yml as follows:

1. If you're installing the plugin from PyPI:

pip_url: "meltanolabs-target-postgres[faker]=="

2. If you're installing the plugin from the Git repository:

# Note the nested quotes
pip_url: "'meltanolabs-target-postgres[faker] @ git+https://github.com/MeltanoLabs/target-postgres.git@'"

Installation

Using pipx

pipx install meltanolabs-target-postgres

Using uv

uv tool install meltanolabs-target-postgres

Configuration

An Explanation of Various SSL Configuration Options

There are two distinct processes which both fall under the banner of SSL. One process occurs when the client wishes to ensure the identity of the server, and is the more common reason that SSL is used. Another is when the server wishes to ensure the identity of the client, for authentication/authorization purposes.

If your server is set up with a certificate and private key, and you wish to check their certificate against a root certificate which you posess, use ssl_enable. You may then further customize this process using the ssl_certificate_authority and ssl_mode settings. See the documentation for further details.

If your server is set up with a root certificate, and you wish to provide a certificate to the server to verify your identity, use ssl_client_certificate_enable. You may then further customize this process using the ssl_client_certificate and ssl_client_private_key settings. See the documentation for further details.

Configure using environment variables

This Singer target will automatically import any environment variables within the working directory's .env if the --config=ENV is provided, such that config values will be considered if a matching environment variable is set either in the terminal context or in the .env file.

Source Authentication and Authorization

The database account provided must have access to:

1. Create schemas
2. Create tables (DDL)
3. Push Data to tables (DML)

Usage

You can easily run target-postgres by itself or in a pipeline using Meltano.

Executing the Target Directly

target-postgres --version
target-postgres --help
# Test using the "Carbon Intensity" sample:
pipx install git+https://gitlab.com/meltano/tap-carbon-intensity
tap-carbon-intensity | target-postgres --config /path/to/target-postgres-config.json

Using Docker Compose

docker-compose.yml provides the commands to create two empty sample databases using Docker. These can be a starting point to create your own database running in Docker, or can be used to run the tap's built-in tests.

Developer Resources

Initialize your Development Environment

pipx install poetry
poetry install
pipx install pre-commit
pre-commit install

Setting Up SSL Files

We have set the provided keys in the .ssl directory to be valid for multiple centuries. However, we have also provided configuration instructions below to create all of the necessary files for testing SSL.

A list of each file and its purpose:

1. ca.crt: CA for client's certificate (stored on the server)
2. cert.crt: Client's certificate (stored on the client)
3. pkey.key: Client's private key (stored on the client)
4. public_pkey.key: Client's private key with incorrect file permissions (stored on the client)
5. root.crt: CA for server's certificate (stored on the client)
6. server.crt: Server's certificate (stored on the server)
7. server.key: Server's private key (stored on the server)

Run the following command to generate all relevant SSL files, with certificates valid for two centuries (73048 days).

openssl req -new -x509 -days 73048 -nodes -out ssl/server.crt -keyout ssl/server.key -subj "/CN=localhost" &&
openssl req -new -x509 -days 73048 -nodes -out ssl/cert.crt -keyout ssl/pkey.key -subj "/CN=postgres" &&
cp ssl/server.crt ssl/root.crt &&
cp ssl/cert.crt ssl/ca.crt &&
cp ssl/pkey.key ssl/public_pkey.key &&
chown 999:999 ssl/server.key &&
chmod 600 ssl/server.key &&
chmod 600 ssl/pkey.key &&
chmod 644 ssl/public_pkey.key

Now that all of the SSL files have been set up, you're ready to set up tests with pytest.

Create and Run Tests

Start the test databases using Docker Compose:

docker-compose up -d

Create tests within the target_postgres/tests subfolder and then run:

poetry run pytest

You can also test the target-postgres CLI interface directly using poetry run:

poetry run target-postgres --help

Testing with Meltano

Note: This target will work in any Singer environment and does not require Meltano. Examples here are for convenience and to streamline end-to-end orchestration scenarios.

Your project comes with a custom meltano.yml project file already created.

Next, install Meltano (if you haven't already) and any needed plugins:

# Install meltano
pipx install meltano
# Initialize meltano within this directory
meltano install

Now you can test and orchestrate using Meltano:

# Test invocation:
meltano invoke target-postgres --version

SDK Dev Guide

See the dev guide for more instructions on how to use the Meltano SDK to develop your own Singer taps and targets.

Data Types

The below table shows how this tap will map between jsonschema datatypes and Postgres datatypes.

Note that while object types are mapped directly to jsonb, array types are mapped to a jsonb array.

If a column has multiple jsonschema types, the following order is using to order Postgres types, from highest priority to lowest priority.

• BYTEA
• ARRAY(JSONB)
• JSONB
• TEXT
• TIMESTAMP
• DATETIME
• DATE
• TIME
• DECIMAL
• BIGINT
• INTEGER
• BOOLEAN
• NOTYPE

Content Encoding Support

Json Schema supports the contentEncoding keyword, which can be used to specify the encoding of input string types.

This target can detect content encoding clues in the schema to determine how to store the data in the postgres in a more efficient way.

Content encoding interpretation is disabled by default. This is because the default config is meant to be as permissive as possible, and do not make any assumptions about the data that could lead to data loss.

However if you know your data respects the advertised content encoding way, you can enable this feature to get better performance and storage efficiency.

To enable it, set the interpret_content_encoding option to True.

base16

The string is encoded using the base16 encoding, as defined in RFC 4648.

Example schema:

{
  "type": "object",
  "properties": {
    "my_hex": {
      "type": "string",
      "contentEncoding": "base16"
    }
  }
}

Data will be stored as a bytea in the database.

Example data:

# valid data
{ "my_hex": "01AF" }
{ "my_hex": "01af" }
{ "my_hex": "1af" }
{ "my_hex": "0x1234" }

# invalid data
{ "my_hex": " 0x1234 " }
{ "my_hex": "House" }

For convenience, data prefixed with 0x or containing an odd number of characters is supported although it's not part of the standard.