Is it possible to get the list of user-defined Types & Domains that are used in all the stored procedures and user-defined functions?
Not easily, because the body of functions is stored as a string. One would have to parse that, which is particularly difficult, as there are so many procedural languages in PostgreSQL.
You could perform a substring search in the source code, but that is notoriously unreliable.
Related
Let's say a value v of type t is used as follows in a SQL statement: SELECT (v::text)::t;, could this throw an error? Would the behaviour change for types introduced through extensions?
The documentation observes:
You should be careful to make the input and output functions inverses of each other. If you do not, you will have severe problems when you need to dump your data into a file and then read it back in. This is a particularly common problem when floating-point numbers are involved.
This shows the design principle that the built-in types adhere to when it comes to text input and output, and cast to and from text typically uses these functions.
So yes, it is like you want for built in types — mostly.
There are small exceptions, and the quotation hints at one of them: casting a double precision to and from text cannot be completely faithful, and you can lose (insignificant) digits (unless you set extra_float_digits to 3).
So that will work well for the built-in types. One simple reason why this is necessary is that otherwise pg_dump and pg_restore would not be able to create a dump that can be restored without data loss.
With user-defined types it depends on how well the implementors implemented the design principle. Usually they have to, since otherwise they would break pg_dump.
I came across the send_function and receive_function for user-defined types in Postgresql (see Manual entry on CREATE TYPE). It says there that both functions are used to participate in binary input/output. I don't really understand what is meant by that? How can I use binary input and output? Is that the case when I access the database via a ODBC/JDBC driver?
Binary input and output is supported for binary COPY and, yes, for binary transfer in the PostgreSQL wire protocol.
In many situations binary transfer actually performs worse than text transfer. It is only recommended for very select situations. Unless you have a very specific problem to solve, you do not need binary transfers.
PgJDBC supports the binary PostgreSQL protocol. I don't know if the ODBC driver does. You shouldn't generally use it anyway.
We're setting up a new project and I was wondering if hstore (nosql/key=>value) would appropriate to use in this situation.
We have ~5k providers with fairly standard fields like agency name, first and last names, etc... but there 9 or so other fields that I think could all be incorporated into an hstore column: languages spoken, services provided, funding/payment types accepted, etc... basically many to one relations. A provider of N services may speak English, Spanish and Russian for example.
Searches will need to be run on this data - like finding a provider for respite that speaks Russian and takes Medicare.
So is an hstore OK, or should this be a traditional relational setup?
If the fields are of a uniform setup, the overall management of using traditional columns/indexes will be less trouble and perform a little faster than using hstore. The main reason you would want to use hstore is when the keys are not uniform from one instance to the next, and you still need to perform regular queries on those keys.
I want to write some queries which can work in almost all the databases without any SQLExceptions. So, where can I get the ANSI standards to write the queries ?
Not sure that'll help you.
Vendors are touch and go as far as standards implementation and often the standards themselves are imprecise enough such that you could never write a query that would work with all implementors.
For example, SQL 92 defines the concatenation operator as || but neither MySQL nor MSSQL use this (Oracle does). Vendor independent string concatenation is impossible.
Similarly, a standard escape character is not specified so how you handled that might not work in all vendors.
Having said that:
SQL 92:
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Wiki article with links to SQL 99 ISO documents:
http://en.wikipedia.org/wiki/SQL:1999
From wikipedia:
The SQL standard is not freely available. The whole standard may be purchased from the ISO as ISO/IEC 9075(1-4,9-11,13,14):2008.
Nevertheless I would not advise you to follow this strategy because no database engine follows any SQL standard (SQL 99, 2003, etc.) to the letter. All of them take liberties in the way they handle instructions or define variables (for example, when comparing two strings different engines handle case sensitivity differently). A method that is very efficient with one engine can be terrible inefficient for another.
A suggestion would be to develop a standard group of queries and develop different classes that contain the specific implementation of that query for a certain target RDBMS.
Hope this helped
Check out the BNF of the core SQL grammars available at http://savage.net.au/SQL/
This is part of the answer - the rest, as pointed out by Kiranu and MattMitchell, is that different vendors implement the standard differently. No DBMS adheres perfectly to even SQL-92, though most are pretty close.
One observation: the SQL standard says nothing about indexes - so there is no standard syntax for creating an index. It also says nothing about how to create a database; each vendor has their own mechanisms for doing that.
The Sql-92 standard is probably the one you want to target. I believe it's supported most of the major RDBMSs.
Here is a less terse link. Sample content:
PostgreSQL Has views. Breaks standard by not allowing updates to views...
DB2 Conforms to at least SQL-92.
MSSQL Conforms to at least SQL-92.
MySQL Conforms to at least SQL-92.
Oracle Conforms to at least SQL-92.
Informix Conforms to at least SQL-92.
Something else you might consider, if you're using .NET, is to use the factory pattern in System.Data.Common which does a good job of abstracting provider specifics for a number of RDBMSs.
If you are trying to make a product that will work against multiple databases I think trying to only use standard sql is not the way to go, as other answers have indicated, due to the different 'interpretations' of the standard. Instead you should if possible have some kind of data access layer in your application which has different implementations specific for each database. Depending on what you are trying to do, there are tools such as Hibernate which will so a lot of the heavy lifting in regards to this for you.
Besides the syntactic sugar and expressiveness power what are the differences in runtime efficiency. I mean, plpgsql can be faster than, lets say plpythonu or pljava? Or are they all approximately equals?
We are using stored procedures for the task of detecting nearly-duplicates records of people in a moderately sized database (around 10M of records)
plpgsql provides greater type safety I believe, you have to perform explicit casts if you want to perform operations using two different columns of similar type, like varchar and text or int4 and int8. This is important because if you need to have your stored proc use indexes, postgres requires that the types match exactly between join conditions (edit: for equality checks too I think).
There may be a facility for this in the other languages though, I haven't used them. In any case, I hope this gives you a better starting point for your investigation.
plpgsql is very well integrated with SQL - the source code should be very clean and readable. For SQL languages like PLJava or PLPython, SQL statements have to be isolated - SQL isn't part of language. So you have to write little bit more code. If your procedure has lot of SQL statements, then plpgsql procedure should be cleaner, shorter and little bit faster. When your procedure hasn't SQL statements, then procedures from external languages can be faster - but external languages (interprets) needs some time for initialisation - so for simple task, procedures in SQL or plpgsql language should be faster.
External languages are used when you need some functionality like access to net, access to filesystem - http://www.postgres.cz/index.php/PL/Perlu_-_Untrusted_Perl_%28en%29
What I know - people usually use a combination of PL languages - (SQL,plpgsql, plperl) or (SQL, plpgsql, plpython).
Without doing actual testing, I would expect plpgsql to be somewhat more efficient than other languages, because it's small. Having said that, remember that SQL functions are likely to be even faster than plpgsql, if a function is simple enough that you can write it in just SQL.