I am trying to use guardian_db for managing jwts.
However, when I try to migrate guardian_db schema, it triggers an error, (undefined_object) type "jsonb" does not exist.
I found a similar issue on github ecto repository, https://github.com/elixir-ecto/ecto/issues/1078. It says jsonb is supported from Postgres 9.4.
I am using Postgres 9.6.1 but still experiencing this issue.
Any suggestions?
Related
I have this issue related to the pages search, on the admin side of wagtail. This is the Django Error:
ProgrammingError at /admin/pages/search/
function ts_rank(unknown, text, tsquery) does not exist
LINE 1: ...ry"."body") ## (to_tsquery('''irp''')) ORDER BY ((ts_rank('{...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
When i debug the wagtail code, the pages query result returns this:
Unable to get repr for <class 'wagtail.search.backends.database.postgres.postgres.PostgresSearchResults'>
After looking at wagtail 4 documentation, there's no info about the postgres search engine. Only in documentation up to 2.15 version. And this:
WAGTAILSEARCH_BACKENDS = {
"default": {
"BACKEND": "wagtail.search.backends.database",
}
}
...should work with Postrgres from then on.
The data base was originally in SQLite and then i migrated to Postgres with pgloader
Is there any configuration/upgrade I missed to make wagtails admin search work with postgres? Can the problem be an error caused by the migration?
After talking with Wagtail Support via Slack they've told me that the error is caused by the pgloader migration. Since it was a small project on-develpoment project i decided to rerun the migrations in a new database but it's not the best solution if you have lots of data already.
As pointed by amazon that PostgreSQL 9.3 is deprecated and need to upgrade our version of PostgreSQL to upper version, we just upgraded our version to 9.4. But after upgrade we are not able to do any save() operation from your Yii 1.1 project locally but the operation is working fine from the server.
When we try to run our project from locally and connect the remote PostgreSQL, we got the below error.
{"error":"SQLSTATE[3F000]: Invalid schema name: 7 ERROR: schema
\"publicubfo06sm23qicfa8kmm0nrv3td81qf928i\" does not
exist","try":"end"}
When I try to see my existing schemas using,
SELECT table_name FROM information_schema.tables
I got 3 values namely 'public','pg_catalog', 'information_schema'
Also want to mention that previously with our version 9.3 we were able to do model operations on Yii 1.1 like $model->save() and then immediately get back the primary key value using $model->id or $model->getPrimaryKey() but now it is not working. Only the $lastId = Yii::app()->db->getLastInsertID('tbl_user_group_id_seq'); way is working now.
Can anyone point me out what is the reason behind it? is something get lost while upgrading from 9.3 to 9.4 like schema, role, sequence or anything else that is causing the errors now to access my RDS from local machine.
In my Postgres 9.6 environment, when I try to execute "MERGE INTO" query, it throws me following error:
ERROR: syntax error at or near "MERGE"
LINE 1: MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id W...
^
It seems like it does not support MERGE query. However when I do google, it seems that MERGE is supported by Postgres since version 9.1.
Please tell me whats going wrong here.
Edit: Following are the sources from where I found MERGE support in Postgres.
https://wiki.postgresql.org/wiki/MergeTestExamples
Postgres does not support the MERGE feature.
See https://www.postgresql.org/docs/9.6/unsupported-features-sql-standard.html
F312 | MERGE statement | consider INSERT ... ON CONFLICT DO UPDATE
Also in the latest version (currently 14) it is not supported.
MERGE aka INSERT ... ON CONFLICT DO NOTHING/UPDATE or UPSERT is only available to postgres 9.5 and later:
Note: MERGE is often used interchangeably with the term UPSERT.
UPSERT functionality will be in the PostgreSQL 9.5 release -- see
What's new in PostgreSQL 9.5 MERGE is not in 9.4.5 (the latest
PostgreSQL release as of 2015-10-08)
I am looking for Impala Foreign Data Wrapper for Postgres 9.5. I have tried to figure out from the internet and can only have one reference to https://github.com/lapug/impala_fdw
But it seems the fdw is yet to be completed as per the readme file.
Can someone guide me to any other Impala FDW available which I can use to connect Postgres to Impala?
Since Impala supports JDBC and ODBC, you've got some options.
My jdbc2_fdw fork with 9.5 patches - compiles and able to retrieve results. Not fully tested yet. Incorporates mc-soi's jdbc2_fdw patch for PostgreSQL 9.5 and includes additional changes.
jdbc2_fdw - only works with PostgreSQL 9.4 and earlier
odbc_fdw
I'm using odbc_fdw and heimir-sverrisson's jdbc2_fdw successfully with PostgreSQL 9.4.
PostgreSQL 9.5 changed the API. I just got the jdbc2_fdw working to some degree, but had to do additional patches on the path I mentioned. It allows retrieving results from a foreign table and creating a materialized view on it. More testing is needed. Link shared above.
I have a database that I've been using since a while now. I improved its schema a bit and wanted the compare the differences between the new schema and the old schema and so I dumped both schemas and did a diff. In the old schema, I'm seeing some 'OPERATOR FAMILY' statements that are not visible in the new schema. If it makes any difference, these 'OPERATOR FAMILY' statements relate to the tsearch2 contrib package for PostgreSQL (eg: 'CREATE OPERATOR FAMILY gin_tsvector_ops', etc). The 'OPERATOR CLASS' statements relating to tsearch2 operators are present in both the schemas. Also all of the added 'OPERATOR FAMILY' statements are followed by 'OPERATOR CLASS' statements of the same name, though the 'OPERATOR CLASS' statements are found in both the schemas.
Where it gets really strange is that when I create a database with the new schema, dump its schema using pg_dump, restore it in another database using pg_restore and then dump it again - the 'OPERATOR FAMILY' statements show up! I grep'd the contrib directory but I can't find any 'CREATE OPERATOR FAMILY' statements.
Anyone had a similar experience? Any ideas what might be introducing those statements?
In response to your comment, I would guess the PostgreSQL version migration caused this. In 7.2 tsearch2 was an external contrib module, but in PostgreSQL 8.3 it was integrated into core. So those missing OPERATOR FAMILYs probably come from PostgreSQL 8.3's pg_catalog instead of your own schema.
But I think you can fix it up using the contrib/uninstall_tsearch2.sql script (usually in /usr/share/postgresql-VER/contrib/) to uninstall and then re-install with the contrib/tsearch2.sql script. Ignore any errors you get, those should be safe, since you can't drop types that you're currently using in your tables.