phraseto_tsquery in PostgreSQL 9.5x or just from 9.6x? - postgresql

I'm finding references in the 9.5 manual to phraseto_tsquery
https://postgrespro.com/docs/postgrespro/9.5/textsearch-controls
But if I use it in my query it gives me this error:
No function matches the given name and argument types.
SELECT phraseto_tsquery('english', 'The Fat Rats');
Was this function not added with 9.5 as intended or is it likely there's some other problem on my side. Running 9.5.4 of the database currently. Anyone that can confirm?

For anyone looking; took the step to install postgresql 9.6beta4 and I'm no longer receiving the error message. In other words phraseto_tsquery seems to only be fully supporting in the current 9.6 beta and upcoming full release.

Related

Getting Invalid schema name error on postgresql RDS after upgrading from 9.3 to 9.4

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.

MERGE INTO not working with Postgres 9.6

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)

Connection validation error using postgresql jdbc 4.2 driver against a 9.3 database -- apparent case-sensitivity of SEARCH_PATH keyword

Using the jdbc4.2 implementation contained in postgresql-9.4.1212.jar, I generate an error when calling the java.Sql.Connection isValid() method on a connection to a postgresql 9.3 database (java8 and postgres both running on windows 7).
The path to producing the error is complicated but reproducible (will provide relevant code shortly) and involves a sequence of sql calls on a single db connection whose default schema is reconfigured prior to each use via an explicit execution of SET SEARCH_PATH='[some schema]'.
I find that the error occurs if and only if I render the SEARCH_PATH keyword using upper case (that is, the error does not occur if I execute SET search_path='[some schema]' - only when I execute SET SEARCH_PATH='[some schema]').
Note that the direct effect of executing either variant is the same -- in both cases the default schema associated with the connection is changed to [some schema]. It's just that, eventually, a downstream call to java.sql.connection.isValid() causes the database to crash if I've used SEARCH_PATH instead of search_path.
I can see that the jdbc driver's implementation of java.sql.connection.setSchema() uses the lower-case variant; something that makes me think this apparent case-sensitivity may be a known issue, but I have found no mentions of it anywhere online.
Note that the problem does not occur if I either: (1) use an older jdbc driver (postgresql-9.3.1100.jdbc4.1.jar) with my 9.3 database, or (2) use the latest jdbc driver with a postgresql 9.6 database.
I'm wondering if anyone has run into this specific problem, and also, if there are other known incompatibilities b/w the 9.3 database and the latest jdbc driver.
The driver is failing to invalidate the prepared statement cache because it only detects SET search_path=... when the config parameter is lower case.
See line 2056 of this commit.
I can't find an issue that describes this. Please have a look yourself and raise one if needed.

PostgreSQL error logging options not recognised

As noted here I'm trying to use the PostgreSQL COPY ERROR_LOGGING, ERROR_LOGGING_SKIP_BAD_ROWS options.
My SQL looks like this:
COPY users FROM 'C:\Users\admin\osmosis_temp\users.txt'
(ERROR_LOGGING, ERROR_LOGGING_SKIP_BAD_ROWS);
I get an SQL output of ERROR: option "error_logging" not recognized. Am I missing something that turns on the error logging in the first place?
PostgreSQL 9.3
At the top of the wiki page you've linked to one reads:
Error logging in COPY was a proposed feature developed by Aster Data against the PostgreSQL 9.0 code base. It was submitted and reviewed (1) but not accepted into the core product for that or any other version so far.
So that was only a concept.

PostgreSQL: After using CreateLang, I still get an error "42704: language "plpgsql" does not exist"

I am using pgProvider on a MVC3 Mono application and had no issues on Windows Postgres 9.2. I am migrating to my production Linux/Mono environment, and received an error when attempting to access the provider:
"42704: language "plpgsql" does not exist"
I am using postgreSQL 8.4 on CentOS 6.3
I looked at some info, and ran the following:
createlang -d dbname plpgsql
When I run it again, it affirms that the database is already there.
I restarted postgresql and my app. However, I still get the above error.
Does anyone have any info on why I would still receive an "plpgsql does not exist -- after it is installed?"
In general this sort of error is an indication that something is not as you expect and you need to challenge your assumptions.
Please note that languages do not require restarting the database server to take effect on any version of PostgreSQL. Also note that what languages are allowed in PostgreSQL is a per-db catalog entry (languages, unlike users and roles, are not cluster-global).
So in troubleshooting this, you need to start with:
Is this the right db? The right server?
Is my application connecting to the same db/server I think it is?
Given that createlang affirms that the language exists after you run it, this can't be an issue with PostgreSQL raising a phony error. Instead it must be a problem with the changes you made not affecting the database your application is using.