I have a really old PostgreSQL version - 8.3 and we would like to upgrade it to 8.4. It shouldn't be hard but I am worrying what will happen when function written by my own was added in newer version. By example I wrote function A(text) and function with exactly the same name and parameter was added in PostgreSQL 8.4. What will happen? My function will get override, I'll get some conflict or my function will be the valid one and PostgreSQL won't add it's own?
All built-in functions are stored in the schema pg_catalog. All functions you wrote yourself are stored in a different schema (typically public).
As the "primary key" to identify a function is the schema and the name, there is no clash between your functions and any built-in function.
Related
PostgreSQL has excellent support for evaluating JSONPath expressions against JSON data.
For example, this query returns true because the value of the nested field is indeed "foo".
select '{"header": {"nested": "foo"}}'::jsonb #? '$.header ? (#.nested == "foo")'
Notably this query does not reference any schemas or tables. Ideally, I would like to use this functionality of PostgreSQL without creating or connecting to a full database instance. Is it possible to run PostgreSQL in such a way that it doesn't have schemas or tables, but is still able to evaluate "standalone" queries?
Some other context on the project, we need to evaluate JSONPath expressions against JSON data in both a Postgres database and Python application. Unfortunately, Python does not have any JSONPath libraries that support enough of the spec to be useful to us.
Ideally, I would like to use this functionality of PostgreSQL without creating or connecting to a full database instance.
Well, it is open source. You can always pull out the source code for this functionality you want and adapt it to compile by itself. But that seems like a large and annoying undertaking, and I probably wouldn't do it. And short of that, no.
Why do you need this? Are you worried about scalability or ease of installation or performance or what? If you are already using PostgreSQL anyway, firing up a dummy connection to just fire some queries at the JSONB engine doesn't seem too hard.
PostgreSQL features a contrib module called amcheck. This module provides functions that allow you to verify the logical consistency of the structure of relations. Its functionalities originally appeared in PostgreSQL 10.
Where does the name come from? I understand the check part of the name, but what is the meaning of am?
“am” stands for access method, which is a way to access a table. You can find the same abbreviation in the system catalog pg_am, which lists all known access methods.
A historical note: the module was added in v10 with this commit after this discussion. Originally it only supported checks in B-tree indexes. Back then, “am” was roughly equivalent to “index type” in PostgreSQL slang, so the module name would have been understood as “index integrity check”. PostgreSQL v12 introduced table access methods (other ways to store data in tables), so that the meaning of access method has broadened. In v14, amcheck got a new function verify_heapam to check the integrity of tables, so the name “amcheck” has stood the test of time.
Postgres version: 9.3.4
I have the need to execute a function which resides in a remote database. The function returns a table of statistic data based on the parameters given.
I am in effect only mirroring the function in my local database to lock down access to this function using my database roles and grants.
I have found the following which seem to only provide table-based access.
http://www.postgresql.org/docs/9.3/static/postgres-fdw.html
http://multicorn.org/foreign-data-wrappers/#idsqlalchemy-foreign-data-wrapper
First question: is that correct or are there ways to use these libraries for non-table based operations?
I have found the following which seems to provide me with any SQL operation on the foreign database. The negative seems to be increased complexity and reduced performance due to manual connection and error handling.
http://www.postgresql.org/docs/9.3/static/dblink.html
Second question: are these assumptions correct, and are there any ways to bypass these concerns or libraries/samples one can begin from?
The fdw interface provides a way to make a library which can allow a postgresql database to query any external data source as though it was a table. From that point of view, it could do what you want.
The inbuilt postgresql_fdw driver, however, does not allow you to specify a function as a remote table.
You could write your own fdw driver, possibly using the multicorn library, or some other language. That is likely to be a bit of work though, and would have some specific disadvantages, in particular I don't know how you would pass parameters to the function.
dblink is probably going to be the easiest solution. It allows you to execute arbitrary SQL on the remote server, returning a set of records.
SELECT *
FROM dblink('dbname=mydb', 'SELECT * FROM thefunction(1,2,3)')
AS t1(col1 INTEGER, col2 INTEGER);
There are other potential solutions but they would all be more effort to set up.
I need to write an update script that will check to see if certain tables, indexes, etc. exist in the database, and if not, create them. I've been unable to figure out how to do these checks, as I keep getting Syntax Error at IF messages when I type them into a query window in PgAdmin.
Do I have to do something like write a stored procedure in the public schema that does these updates using Pl/pgSQL and execute it to make the updates? Hopefully, I can just write a script that I can run without creating extra database objects to get the job done.
If you are on PostgreSQL 9.1, you can use CREATE TABLE ... IF NOT EXISTS
On 9.0 you can wrap your IF condition code into a DO block: http://www.postgresql.org/docs/current/static/sql-do.html
For anything before that, you will have to write a function to achieve what you want.
Have you looked into pg_tables?
select * from pg_tables;
This will return (among other things) the schemas and tables that exist in the database. Without knowing more of what you're looking for, this seems like a reasonable place to start.
There is a note in 8.3 doc which explain why my company application is broken after I upgraded Postgresql from 8.1 to 8.3.
Is there an easy way of altering 8.3 version to behave like 8.1? For example: now with 8.3 when I pass data type to the substr function as first argument then I get an error. 8.1 version silently converted data value to string value.
The application is too big and implicit conversion wound solve the problem.
Peter Eisentraut, a PG developer created a SQL script which adds the missing casts. You can get it here.