Need to extract the source of a PostgreSQL function using SQL.
I am seeing this odd behavior with one of the function, all other functions (around 200+ ) work absolutely fine.
When I run the following statement, it works:
select prosrc from pg_proc where proname= 'accounts_count';
However when I run the following, it returns an empty string:
select routine_definition
from information_schema.routines
where specific_name = 'accounts_count_66243'
PostgreSQL version 8.3. I have tried using both pgAdmin III and psql.
Not a show stopper, but would be useful to know why this might be.
Any ideas anyone?
if you look on definition of information_schema.routines, then you can find following filter:
FROM pg_namespace n, pg_proc p, pg_language l, pg_type t, pg_namespace nt
WHERE n.oid = p.pronamespace AND p.prolang = l.oid AND p.prorettype = t.oid
AND t.typnamespace = nt.oid AND (pg_has_role(p.proowner, 'USAGE'::text)
OR has_function_privilege(p.oid, 'EXECUTE'::text));
so my theory:
there are some issue in rights and ownership of related function (probably) - try to use different account for validation of this theory (postgres is best)
Related
I am trying to write a function to determine the sequences related to a given table name, in the query within the function, I went with something like this:
select s.relname as sec from pg_class s
join pg_depend d on d.objid=s.oid and d.classid='pg_class'::regclass
and d.refclassid='pg_class'::regclass
join pg_class t on t.oid=d.refobjid
join pg_namespace n on n.oid=t.relnamespace
join pg_attribute a on a.attrelid=t.oid and a.attnum=d.refobjsubid
where s.relkind='S' and t.relname = 'table_name'
However it doesn't seem to find all the sequences that exists, i.e. for some tables, it just doesn't find the related sequences, but for certain ones it does.
How to take entire database store procedures full scripts same as the MS SQL 2008 R2 Generate Script feature. Need help.
The following query will return the complete DDL statements for each function that is owned by the current user in the schema public:
select pg_get_functiondef(p.oid)||';'
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
join pg_user u on u.usesysid = p.proowner
where n.nspname = 'public'
and p.prokind <> 'a'
and u.usename = current_user;
prokind <> 'a' is necessary because pg_get_functiondef() doesn't work with user defined aggregate functions.
If you want the functions from a different schema or owner, just change the where conditions accordingly.
You can spool the output to a file to get a SQL script containing all functions.
I have a lot of functions and stored procedures in my PostgreSQL database that is dependent on each other. I want to run a script that will compile those function fist which is independent and not referring any other functions. Then I want to compile next level functions and so on until I reach top level function.
SQL Server has sys.sql_expression_dependencies table which keeps track of referencing objects and referenced objects? Do we have anything like that in Postgres? if not how to achieve it.
What is reason? PostgreSQL PL/pgSQL functions has not compile (better validation) time dependency. There is runtime dependency only. Currently there is not a tool for this purpose, what I know. But some dependency can be taken from PL profiler https://bitbucket.org/openscg/plprofiler.
You can try this query:
select t.*, f.* from
(
SELECT table_name,table_schema,
table_schema||'.'||table_name full_name,
table_type
FROM information_schema.tables
WHERE table_schema not in ('information_schema') and table_schema not like 'pg%'
) t
JOIN
(
SELECT n.nspname AS schema_name,
p.proname AS function_name,
pg_get_function_arguments(p.oid) AS args,
pg_get_functiondef(p.oid) AS func_def
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname not in ('pg_catalog','information_schema') and n.nspname not like 'pg%'
) f
on position(t.table_name in f.func_def) >0
How to see all the built-in general-purpose data types, which support postgresql? For example from phppgadmin is possible to browse all types, but how to get types list via query, something like this:
SELECT data_types from ....
Something like this:
select ns.nspname as schema_name, t.typname as type_name
from pg_type t
join pg_namespace ns on ns.oid = t.typnamespace
where t.typtype in ('b')
and t.typelem = 0;
pg_type contains an entry for each and every type in the database, that includes the composite type that is created for a table and so on. The above query tries to filter out those that might not be interesting for you. You will have to play around with it to make it fit your needs.
pg_type is documented in the manual: http://www.postgresql.org/docs/current/static/catalog-pg-type.html
I have an application that reads the structure of an existing PostgreSQL 9.1 database, compares it against a "should be" state and updates the database accordingly. That works fine, most of the time. However, I had several instances now when reading the current database structure deadlocked. The query responsible reads the existing foreign keys:
SELECT tc.table_schema, tc.table_name, tc.constraint_name, kcu.column_name,
ccu.table_schema, ccu.table_name, ccu.column_name
FROM information_schema.table_constraints AS tc
JOIN information_schema.key_column_usage AS kcu
ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage AS ccu
ON ccu.constraint_name = tc.constraint_name
WHERE constraint_type = 'FOREIGN KEY'
Viewing the server status in pgAdmin shows this to be the only active query/transaction that's running on the server. Still, the query doesn't return.
The error is reproducible in a way: When I find a database that produces the error, it will produce the error every time. But not all databases produce the error. This is one mysterious bug, and I'm running out of options and ideas on what else to try or how to work around this. So any input or ideas are highly appreciated!
PS: A colleague of mine just reported he produced the same error using PostgreSQL 8.4.
I tested and found your query very slow, too. The root of this problem is that "tables" in information_schema are in fact complicated views to provide catalogs according to the SQL standard. In this particular case, matters are further complicated as foreign keys can be built on multiple columns. Your query yields duplicate rows for those cases which, I suspect, may be an undesired.
Correlated subqueries with unnest, fed to ARRAY constructors avoid the problem in my query.
This query yields the same information, just without duplicate rows and 100x faster. Also, I would venture to guarantee, without deadlocks.
Only works for PostgreSQL, not portable to other RDBMSes.
SELECT c.conrelid::regclass AS table_name
, c.conname AS fk_name
, ARRAY(SELECT a.attname
FROM unnest(c.conkey) x
JOIN pg_attribute a
ON a.attrelid = c.conrelid AND a.attnum = x) AS fk_columns
, c.confrelid::regclass AS ref_table
, ARRAY(SELECT a.attname
FROM unnest(c.confkey) x
JOIN pg_attribute a
ON a.attrelid = c.confrelid AND a.attnum = x) AS ref_columns
FROM pg_catalog.pg_constraint c
WHERE c.contype = 'f';
-- ORDER BY c.conrelid::regclass::text,2
The cast to ::regclass yields table names as seen with your current search_path. May or may not be what you want. For this query to include the absolute path (schema) for every table name you can set the search_path like this:
SET search_path = pg_catalog;
SELECT ...
To continue your session with your default search_path:
RESET search_path;
Related:
Get column names and data types of a query, table or view