Sorry for potential FAQ, RTFM, etc. If I understand correctly, transactions could not be used in native scripting units (functions, including anonymous do-blocks). What would PostgreSQL guys recommend as the least "not natural" way to combine scripting and transactions?
I think you are talking about autonomous transactions.
If so, you are correct that PostgreSQL doesn't support true stored procedures with autonomous transactions yet. (Feel free to sponsor work or contribute time...)
Your options are:
Use dblink to make connections-to-self and do the discrete units of work that way
Use an external process that connects to Pg
Use an in-db script with pl/python, pl/perl, etc that connects to the DB using psycopg2 / DBD::Pg / etc, rather than using the SPI, and does the work that way. Essentially you code the script like an externally connecting script, but run it within the DB for convenience.
Related
Recently I've been asigned to migrate part of the database from Oracle to PostgreSQL enviroment, as testing experiment. During that process, major drawback that occured to me was lack of simple way to implement parallelism which is required due to multiple design reasons, which aren't so relevant here. Recently I've discovered https://www.postgresql.org/docs/11/bgworker.html following process, which occured to me as some way to solve my problems.
Yet not so truly, as I couldn't easly find any tutorial or example how to implement it even for a simple task as writing debugmessages into logger, while the process is running. I've tried some old ways, presented in some plugin specifications from version 9.3, but they weren't much of help.
I would like to know how to set up those workers properly. Any help would be appriciated.
PS: Also if some good soul found workaround to implement bulk collect for cursors into PostgreSQL it would be most kind of you, to share it.
The documentation for bgworker that you linked to is for writing C code, which is probably not what you want. You can use the pg_background extension, which will do what you want. ora2pg will optionally use pg_background when converting oracle procedures with the autonomous transaction pragma. The other option is to use dblink to open a connection to the current db.
Neither solution is great, but it's the only way to go if you need to store data in a table whether or not the enclosing transaction succeeds. If you can get by with just putting stuff into the logs, you can use RAISE NOTICE instead.
As far as bulk collect for cursors go, I'm not sure exactly how you are using them, but set returning functions may help you. Functions in postgres can return multiple rows without fiddling with cursors.
I have a Postgresql 9.1 server, and I want to write some functions on Python.
There 2 ways: plpy or psycopg2. For me writing functions in plpy is like nightmare, a lot of "prepare" and "execute" methods... more comfortably to use psycopg2, but I care about efficiency.
Is it correct using psycopg2 on server?
They are 2 different things. plpy (PL/Python) is a stored procedure language like PLpgSQL and psycopg2 is a client library which allows Python code to access a PostgreSQL database. With PL/Python, you will need to make a connection to the database and then call your function from the database. With psycopg2, you would write Python code to call the database. Unless you have specific requirements of writing a Python function that runs from within PostgreSQL itself, use pysocpg2.
For me writing functions in plpy is like nightmare
You've already made your mind up. Even if you use pl/python, any bugs in your code will be attributed to the language or its environment. After a while you will be able to abandon your pl/python code and re-implement it the way you always wanted to*.
The beauty of it is, that as Jim says above the two interfaces do completely different things - one running inside the database within a single transaction, the other outside as normal client code. There's almost no overlap between the use cases for the two languages. Somehow though you've missed that even while making up your mind about which is "good" or "bad".
*We all have our programming predjudices, but I'm not sure there's much point in opening a question with a bold statement of them.
I'm working with an ETL tool, Business Objects Data Services, which has the capability of specifying parallel execution of functions. The documentation says that before you can do this, you have to make sure that your database, which in our case is Postgres, allows "a stored procedure to run in parallel". Can anyone tell me if Postgres does that?
Sure. Just run your queries in different connections, and they will run in parallel transactions. Beware of locking though.
You can also call different stored procedures from the same connection (and effectively still run them in parallel) by using DBLink.
See this SO answer to see an example.
I'm using a sqlServer database that has stored procedures, and I want to use an in-memory database to unit test my code.
I've looked at a few - including VistaDB which looks amazing but expensive - and Blackfish seems to be the only possiblity so far. Before using it though i'd like to know exactly how compatible it is with TSQL - obviously if I have a lot of existing stored procedures these will use TSQL, so it's important that the in-memory db I use can handle this.
Thanks
Short Answer: Not Very
Long Answer:
Whilst Blackfish is SQL-92 compliant, you’re bound to run into stuff that worked on your T-SQL database that won’t work on BlackFish.
I'd strongly recommend SQL Server Compact 4.0 (or Express at a crunch), Compact can be easily bundled, has a tiny footprint (3mb installer? [18mb on disk ish]).
For instance, T-SQL Flow control might differ to Blackfish flow control - not really relevant for selects, inserts & updates etc, but if you have T-SQL logic gates in stored procedures, i don’t think these will port to Blackfish? Blackfish supports stored procedures, but they are compiled in other native languages (Delphi mainly). Good example from the documentation:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/bfsql/storedprocedures_xml.html
Very different from the T-SQL procedures used in MS SQL
I have a database which is part of a closed system and the end-user of the system would like me to write some reports using the data contains in a Sybase SQL Anywhere Database. The system doesn't provide the reports that they are looking for, but access to the data is available by connecting to this ASA database.
The vendor of the software would likely prefer I not update the database and I am basically read-only as I am just doing some reporting. All is good, seal is not broken, warranty still intact, etc,etc..
My main problem is that I am using jConnect in order to read from the database, and jConnect requires some "jConnect Routines" to be installed into the database. I've found that I can make this happen by just doing an "Alter Database Upgrade JConnect On", but I just don't fully understand what this does and if there is any risks associated with it.
So, my question is does anyone know exactly what jConnect routines are and how are they used? Is there any risk adding these to a database? Should I be worried about this?
If the vendor wants you to write reports using jConnect they will have to allow the installation of the JConnect tables.
These are quite safe, where I work the DBA team install these as a matter of course and we run huge databases in production with no impact.
There is an alternative driver that you could use called jTDS. Its open source and supports MS SQL Server and Sybase. I'm not sure if they require the JConnect tables or not.
I think that the additional tables are a bit of anachronism in this day and age.
Looking at ASA 10 docs, there is another driver: the iAnywhere JDBC driver which seems to be going through the ODBC driver, and as such, probably will not require an alteration of the database.
On the other hand, installing the "jConnect system objects" is done by running the script scrits/jcatalog.sql... You can show it the DBAs, if you want to reassure them. It creates some procedures, tables, variables.
The need for this script probably comes from the fact that jConnect talks to both ASE (Sybase) and iAnywhere databases, so it needs a compatibility layer installed in the database...