Declarations before code has been informally supported and we have
several examples in the code. This commit adds that guideline to the
coding guidelines.
This patch removes code support for PG9.6 and PG10. In addition to
removing PG96 and PG10 macros the following changes are done:
remove HAVE_INT64_TIMESTAMP since this is always true on PG10+
remove PG_VERSION_SUPPORTS_MULTINODE
PostgreSQL 12 is supported since 1.7, while 9.6 and 10 are deprecated.
This PR updates the building from source instruction with this change
and uses 1.7.0 in examples.
This commit updates the README with updated resources, including Timescale
Cloud, new support options, release notes, and others. For readability, it
also moves instructions for building from source to a separate readme file.
We are switching from pgindent to clang-format for several
reasons:
1) pgindent is harder to set up and depends on other tools
like gobjdump that differ between OSes making it harder
to set up a proper development environment.
2) clang-format is more standard and works better
with various IDEs and editors.
Our clang-format wrapper script is transactional in that this
version of the script copies all files to a temporary directory,
runs clang-format in the temp dir, and only then copies the files
back. This should prevent mis-formatting when the script is cancled
in the middle of running.
We changes travis to use clang-format instead of pgindent
and thus it uses a different docker image to do the format test.
We also changes travis to use the new clang docker
image for the license check and prefix checks for consistency.
This also paves the way for us to use more clang features for tests
in the future.
This PR removes the need to run setup_timescaledb. It also fixes
pg_dump and pg_restore. Previously, the database would restore in
a broken state because trigger functions were never attached to
meta tables (since setup_timescaledb() was not run). However, attaching
those triggers at extension creation also causes problems since the data
copy happens after extension creation but we don't want triggers fired
on the data restored (that could cause duplicate rows, for example).
The solution to this chicken-and-egg problem in this PR is to have
a special configuration (GUC) variable `timescaledb.restoring` that,
if 'on', would prevent the extension from attaching triggers at
extension creation. Then, after restoration, you'd call
restore_timescaledb() to attach the triggers and unset the GUC above.
This procedure is documented in the README as part of this PR.
If a user attempts to setup a database while not connecting using
the network, port is NULL and thus fails constraint checks. Instead,
we now use the default Postgres port of 5432 when this happens.
Also, setup_db() is renamed to setup_timescaledb() for clarity in
the presence of other extensions.
