I am trying to install pg-cron extension for Azure PostgreSQL Flexible server.
According to documentation found here:
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions#postgres-13-extensions
pg_cron is available extension, but when I am trying to install it:
create schema cron_pg;
CREATE EXTENSION pg_cron SCHEMA cron_pg;
What I get is:
SQL Error [0A000]: ERROR: extension "pg_cron" is not allow-listed for "azure_pg_admin" users in Azure Database for PostgreSQL
Hint: to see the full allow list of extensions, please run: "show azure.extensions;"
When executing:
show azure.extensions;
pg_cron is missing:
address_standardizer,address_standardizer_data_us,amcheck,bloom,btree_gin,btree_gist,citext,cube,dblink,dict_int,dict_xsyn,earthdistance,fuzzystrmatch,hstore,intagg,intarray,isn,lo,ltree,pageinspect,pg_buffercache,pg_freespacemap,pg_partman,pg_prewarm,pg_stat_statements,pg_trgm,pg_visibility,pgaudit,pgcrypto,pgrowlocks,pglogical,pgstattuple,plpgsql,postgis,postgis_sfcgal,postgis_tiger_geocoder,postgis_topology,postgres_fdw,sslinfo,tablefunc,tsm_system_rows,tsm_system_time,unaccent,uuid-ossp,lo,postgis_raster
What am I doing wrong?
You can tell pg_cron to run jobs in another database by updating the database column job in the jobs table.
For example:
UPDATE cron.job SET database = 'wordpress' WHERE jobname = 'wordpress-job';
Pretty late but this issue showed up when I was searching for same problem but with pg_trgm extension. After some looking around eventually realised you just need to update the database settings.
Go to Database in Azure Portal, then to Server parameters and search for azure.extensions parameter. You can then click on the list and enable/disable desired extensions (PG_CRON is available), the server will restart on save and then you will be able to enable the extensions in database.
Seems that the pg_cron extension is already enabled, by default, in the default 'postgres' database.
The reason why I was not seeing this is because I am not using the default 'postgres' database. I have created my own DB which I was connected to.
This actually does not resolve my problem, because I can't execute jobs from pg_cron across databases...
I am trying to use dblink, I have thousands of schemas.
I have tried to install dblink extension using:
create extension dblink schema exampleschema;
Of course I am getting this error:
Error occurred during SQL query execution
Reason:
SQL Error [42710]: ERROR: extension "dblink" already exists
This is not true as I cannot use dblink for specific schema (I am accessing it through the app that I am the dev) as it cannot find it.
Only way to make dblink work is to use set search to a schema were extensions I've managed to install.
I've tried to set search path to a schema where extension is missing
Tried to use above query
Tried to set connection active to selected schema
Can't figure out what I would be able to use...
Extension was only created for public and schema1, however everytime I try to install extension to any other schema I will get information that extension is missing (extensions is not found when using query (when set search path to proper schema) or checking in system info / extensions).
How can I force postgresql to install extension in specific schema ? Is there any other query as obviously above query doesn't work (extensions doesn't exist in exampleschema)
An extension is not installed per schema, but per database.
Extension was only created for public and schema1
You are misunderstanding how an extension is installed.
An extension is installed in one (and only one) schema, which means that all functions that the extension provides are created in that schema. So if you installed the dblink extension in the schema dblink_schema all dblink functions are stored there.
To make that extension available to users that have a different search_path, you need to change that user's search_path to include the schema where the extension is installed in (not to the schema where it's missing), e.g.:
alter user app_user
set search_path = public,dblink_schema;
I've got an existing Postgres 9.6 database on Google Cloud that has the PostGIS extension enabled, however whenever I try to create a table with a column with the geography type or select the PostGIS version I get an error.
For creating the geography column the error is non-descriptive — just an arrow pointing to the word geography in the following statement
create table place(coordinate geography(POINT,4326));
The version error looks as follows:
select postgis_full_version();
ERROR: could not access file "$libdir/postgis-2.3": No such file or directory
CONTEXT: SQL statement "SELECT postgis_lib_version()"
PL/pgSQL function postgis_full_version() line 22 at SQL statement
The create extension statement confirms it is already installed though e.g
create extension postgis;
error: the extension already exists
I've tried running these commands as the postgres user and as another user who's been granted permissions on the database in question but neither seem to work. Any help would be appreciated.
It's simpler than you think:
Your hosting privider has goofed up the PostGIS installation.
It looks like the file is really missing, or something else on the operating system level is misconfigured.
You should gripe at Google.
I use primary pgAdmin to browse and edit my PostgreSQL database. Now I would like to use PhpStorm.
In PhpStorm I can browse my tables, but I can not edit data. When I try I get error:
[42704] ERROR: type "hstore" does not exist
Kde: compilation of PL/pgSQL function "on_update" near line 3
Function on_update is on update trigger and it save old row to history table and it uses hstore type.
PhpStorm uses postgresql-9.4-1201.jdbc4.jar driver. I don't know if it is driver error or PhpStorm error. I know that in pgAdmin it works and in PhpStorm not.
I work with same environment as Vojtěch and I have found that the extension is indeed created and present. But in different schema (public) then the current connection operates (the PostgreSQL search_path). There is probably bug in PhpStorm as its not respecting PostgreSQL user's default search_path.
Some workarounds (for DB console only):
In database console you use RESET SEARCH_PATH; statement.
You can enforce search_path on JDBC connection, see the question.
I'm trying to upload a database, which I developed locally, into our development server.
I installed PostgreSQL 9.1 on my machine and the development server uses 8.4.
When trying to restore the database to 8.4 using the dump file created by 9.1 I get the error:
pg_restore: [archiver (db)] could not execute query: ERROR: syntax error at or near "EXTENSION"
LINE 1: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalo...
and a quick research tells me that "EXTENSION" doesn't exist prior to 9.1.
I'm not really sure I should look for an option in pg_dump that ignores "extensions" as the database I'm trying to upload relies on the PostGIS extension for most of data.
While upgrading the development server and installing PostGIS in the dev server is an option, I'd like to know of a different route, one wherein I do not need to edit anything on the server while maintaining the functions of the database I developed.
Of course other workarounds are welcomed, my sole aim in uploading my database to the server is to reduce the amount of reconfiguration I have to do on my project whenever I need to deploy something for our team.
This is an old post but I had the same problem today and there is a better more reliable way of loading a PG 9.1 db into a PG 8.4 server. The method proposed by Craig will fail on the target machine because the PLPGSQL language will not be created.
pg_dump -Upostgres -hlocalhost > 9.1.db
replace this line
CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
with this line
CREATE LANGUAGE plpgsql;
delete this line or comment it out
COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
you can use sed to make the changes
Often it is not possible to upgrade an 8.4 server because of application dependencies.
Backporting databases can be painful and difficult.
You could try using 8.4's pg_dump to dump it, but it'll probably fail.
You'll probably want to extract the table and function definitions from a --schema-only dump text file, load them into the old DB by hand, then do a pg_dump --data-only and restore that to import the data.
After that, if you're going to continue working on your machine too, install PostgreSQL 8.4 and use that for further development so you don't introduce more incompatibilities and so it's easy to move dumps around.
In your position I'd just upgrade the outdated target server to 9.1.