Connecting GNU R to PostgreSQL - postgresql

I have GNU R installed (the S-like statistics package; version 2.8.1) and PostgreSQL (8.4.1), but I cannot connect GNU R to my RDBMS.
When I first did this (years ago - code lost) DBI for R didn't exist. Now it does. I am also confused as to which R package to use. A quick search returns:
RPostgreSQL seems to be the most up-to-date
RPgSQL Looks abandoned. I wish they would put a date on their webpage. ;-(
My Linux distribution doesn't package R packages (irony) but I am comfortable running R CMD INSTALL package.tar.gz.
I installed RPostgreSQL: a lot of documentation says to call dbConnect but I get the following error message: Error: object "dbConnect" not found.

Just for completeness, you have two more options
RODBC which is very mature and feature-complete but doesn't correspond to the DBI framework as the PostgreSQL, MySQL, SQLite, Oracle, ... interfaces do. You also need to fiddle with ODBC setup files which can be tricky. But ODBC may be useful for other data access uses too.
RdbiPgSQL from the BioConductor project which is also mature but uses yet another protocol that was to compete with DBI and never took of. This PostgreSQL package is featureful though.
But as a RPostgreSQL maintainer/co-author I am glad you found this one. As the other poster suggested, try library(RPostgreSQL) before issueing commands. If you encounter other problems, feel free to email me off-SO with a bug report.
Edit: There is another option of embedding R inside PostgreSQL using Joe Conway's PL/R.

Maybe you need to run require(RPostgreSQL) before you can use dbConnect?

My guess is you need to install the DBI package (most database packages depend on it).
If you use install.packages('RPpostgreSQL',dep=TRUE) from within R it should take care of any dependency issues.

RODBC works great for me. You just have to set up a data source name (DSN) for the database you want to connect to. I find this nice because then the specific connection info does not have to be stored in R, and it may vary for your collaborators.
Also, yes, it sounds like you haven't loaded the RPostgresSQL package.

Related

Stack cannot find libpq when given directory

I am trying to set up a stack project that uses the postgresql-simple package among others. When trying to stack build, all of the dependencies for postgresql-simple installed without issue, but stack is having trouble installing postgresql-simple itself. I get the following error:
C:project> stack build --extra-include-dirs="C:\PostgreSQL\8.4\include" --extra-lib-dirs="C:\PostgreSQL\8.4\lib"
... omitted ...
*****************
--extra-include-dirs=C:\PostgreSQL\8.4\include
*****************
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
*****************
--extra-lib-dirs=C:\PostgreSQL\8.4\lib
*****************************
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\lib
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\User\Desktop\draftkings\NFAccuracy\.stack-work\logs\postgresql-libpq-0.9.1.1.log
Configuring postgresql-libpq-0.9.1.1...
Setup.hs: Missing dependency on a foreign library:
* Missing C library: pq
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
I've tried also specifying the paths in my stack.yaml file, same error.
I've tried manually copying the library and include files from my postgres installation to the mentioned ...\mingw64\lib and ...\mingw64\include folders. Same error.
I have the files libpq.dll and libpq.lib in my C:\PostgreSQL\8.4\lib folder.
I feel like I'm missing something obvious but I can't get this to work and I'm not sure what I'm doing wrong. Any help is appreciated.
Update
I forgot to mention two important details.
First, I have added C:\PostgreSQL\8.4\bin to my PATH. As far as I know, this works as expected, because I got past an error about pg_config missing, to the error I currently have.
Second, I also tried adding the lib and include directories to my PATH, but this did not change the error.
I should also mention my Postgres installation works fine on its own.
I know that the Snowdrift project uses PostgreSQL and builds with Stack on Windows. They have a build guide on their site. It looks like one difference is that they mention:
Add the PostgreSQL bin directory to the path C:\Program Files (x86)\PostgreSQL\9.4\bin
Can you try adding that to the PATH and see if that fixes it?
There was some kind of version mismatch.
Installing Postgres 9.4 instead of 8.4 allowed the postgresql-simple package to be built in the manner I was attempting.
My stack project, without intervention by me, defaulted to using resolver: 'lts-3.7' This provided version 0.4.10.0 of the postgresql-simple package to my project. I wish I had a more detailed answer, but all I can tell is that this version of postgresql-simple (which is fairly recent) works fine with PostgreSQL 9.4 (which is also recent).
And thankfully, using haskell and postgresql-simple built against Postgres 9.4 libraries is having no issue communicating with my 'remote' (virtualbox) database which is Postgres 8.4.
I'm tempted to flag my question as not constructive unless others find this useful info.

Postgresql: ERROR: timezone directory stack overflow

I have an application that deals with timezones, so naturally I want to be able to view the list of timezones in Postgresql.
I tried to view all available timezones with the following command:
SELECT * FROM pg_timezone_names;
Which prints the following error:
ERROR: timezone directory stack overflow
I even tried limiting the results and received the same error:
SELECT * FROM pg_timezone_names LIMIT 10;
At first I thought it might just be my IDE of choice having issues, but I tried to run the same sql query on the command line and received the same error. I can't, for the life of me, find an answer to this issue. Any information would be helpful. Thanks!
EDIT: I'm using Postgresql 9.3 on Gentoo. Self compiled version of postgresql-server.
Note: I can query the pg_timezone_abbrevs table just fine, just not pg_timezone_names.
According to this Postgres FAQ:
...
On platforms that receive regular software updates including new tzdata files, it may be more convenient to rely on the system's copy of the tzdata files. This is possible as a compile-time option. Most Linux distributions choose this approach for their pre-built versions of PostgreSQL.
...
The compile-time option referred to is the --with-system-tzdata, which is described about half-way down this page.
My guess is that this flag is set by the Portage distribution you're using, and that the tzdata is either missing or corrupted on your system. On Gentoo, the tzdata is distributed in the timezone-data package, which you can find here.
Try:
# emerge timezone-data
Then see if that fixes the problem.
This is an answer to my own question.
The following is at least true on the Gentoo distro of linux, but I assume can be present on others.
What causes the error mentioned in my post is a symlink loop by /usr/share/zoneinfo/posix
To solve this error you just have to delete that symlink, as follows:
rm /usr/share/zoneinfo/posix
Pretty easy fix. Be aware that any update to zoneinfo will cause this symlink to be recreated and thus requiring you to remove it again. I haven't had any issues with this link being removed, but I can't say the same for others. If anyone has a reason for NOT deleting this symlink, just post a comment stating so.
Had the exact same issue on Ubuntu 14.04 LTS with PostgreSQL 9.3.3 however my recursive symlink was with /usr/share/zoneinfo/localtime. Fixed by running:
$ sudo unlink /usr/share/zoneinfo/localtime

How to debug postgresql stored procedures?

I realize that there is nothing similar to SQL Server Management Studio, so I am mentally prepared to use the good old printf debugging.
The only question is how to do "printf" from a stored procedure?
To "print" a message, you can use raise notice from within a PL/pgSQL function:
http://www.postgresql.org/docs/current/static/plpgsql-errors-and-messages.html
Note that the client must have set the value of "client_min_messages" to the appropriate level in order to receive the "notice".
pgAdmin has a debugger for functions: http://www.pgadmin.org/docs/1.18/debugger.html
(But I have never use it as I don't use pgAdmin).
It sounds like you're looking for actual debugging capability. PostgreSQL actually introduced this functionality starting with PostgreSQL 8.3.
It's fantastic and totally makes PostgreSQL live up to it's tagline "the world's most advanced open source database". It's kind of a hassle to get running but these links might help get you started. Once enabled it allows you to set breakpoints or define inputs & evaluate functions all through a handy right-click menu in PGAdmin.
Along with the trusty ol' RAISE commands, there are also a couple 3rd-party tools that I have heard of, though I've never used them.
PLPGSQL Lint: https://github.com/okbob/plpgsql_lint
EDB Debugger: http://www.enterprisedb.com/docs/en/9.0/asguide/Postgres_Plus_Advanced_Server_Guide-17.htm. My understanding is that the EnterpriseDB Debugger comes bundled with their Postgres Studio package.
There is a debugger for PGAdmin: I tried this in ubuntu environment with Postgres 12 and it worked for me:
install this package
apt-get install postgresql-12-pldebugger
Run this command in the database where resides your Procedure
CREATE EXTENSION pldbgapi;
In your Postgresql installation folder and precisely in the data folder change this parameter in the postgresql.conf file
shared_preload_libraries = 'plugin_debugger'
NB: you need to restart your Postgres after making this change
in pgAdmin right click on the procedure present in the list of the procedures in your schema, put the values for parameters and choose debug

What's the best way to turn CPAN modules into Debian packages?

Whenever I work on a system of any flavor that has a particular way of handling package management, I try to stick with that standard for managing my Perl modules. "When in Rome, etc."
For example, on a Win32 system using ActivePerl, I use PPM for everything and use the great PPM::Make. On a RedHat system I prefer to use RPMs.
Now I am working on a Debian system, and find myself in need of a way to turn an arbitrary CPAN or CPAN style distribution into a deb.
Google shows options like dh-make-perl, CPANPLUS::Dist::Deb and CPAN::Packager::Builder::Deb.
Does anyone with experience with these different tools have any recommendations as to what to use or avoid?
What's the best way to handle building deb files from standard CPAN modules?
Update:
I found an article by Hans Dieter Piercy on this subject - he suggests, for his own needs, CPANPLUS tools. Under some circumstances he recommends dh-make-perl. Jeremiah Foster (who wrote the article brian d foy points to) responds to HDP and makes a case for dh-make-perl.
There's also a post on idimmu.net that describes using dh-make-perl.
ATM, I'm leaning toward dh-make-perl, since that has been thrice recommended (brian d foy as proxy for Jeremy Foster, the idimmu.net author and hillu) vs once for CPANPLUS
dh-make-perl does a good job in taking care of the repetitive and heavy lifting and guessing information from the sources. It has worked correctly for almost all of the CPAN modules that I have packaged up as Debian packages (official or for in-house use only).
That said, the resulting package should only be considered as a starting point for a proper Debian packages. dh-make-perl puts warning notes into the automatically generated such as debian/control (i.e. description of the package and dependencies) and debian/copyright (licensing information).
In response to Manni, I believe that it is a great idea to work with the tools that the OS or distribution provides for package management, not against them. In the case of Debian, this means putting stuff into .deb packages and installing those. Perl's build tools and CPAN do a great job of providing a cross-platform build environment and for distribution of the source code, but compared to package management tools in modern Linux distributions, they perform suboptimally, simply because extra manual intervention is often required that is less easily automated across multiple machines than rolling up a package.
(For one-off and test installations, installing into /usr/local/ and using stow(8) as a poor man's package manager may be okay.)
Even if you are just building the packages for your own use, consider contacting the Debian Perl Group and have someone sponsor an upload to Debian if you feel that the module in question is of use for other people.
I suggest you ask the Debian Perl Maintainers group, rather than here on SO. Just mail the address shown as maintainer on any odd package:
Debian Perl Group <pkg-perl-maintainers#lists.alioth.debian.org>
Back in the day, I added a few modules to Debian, and just 'did it by hand'. I still maintain some. That isn't hard either. but the group now maintains way more package, and has tools.
Jeremiah Foster published an article about turning Perl distros into Debian packages in the Spring 2009 issue of The Perl Review.
There is a very good step by step here as well. (also with links to other good resources and some decent comments. [it is dated 2005, but still mostly relavent and many comments much more recent])
http://www.debian-administration.org/articles/78
here is the debian perl policy (also linked to in article)
http://www.debian.org/doc/packaging-manuals/perl-policy/
You won't like this, but I really think that you should not do this at all. The various Perl Debian packages aren't for developers that need certain Perl modules on their machines. They were built because other applications need them and users want or might want those applications.
Please take a look at the answers to this question before doing something that you probably should not be doing.

FireBird install using InstallShield

I can't seem to find a good script or anything to use for installing Firebird (the InterBase-decendent RDBMS) using InstallShield. There is a way to silently install it using the firebird install executable, but I don't know enough about InstallShieldscripts to be able to do it! If anyone knows any information on
a) how to execute an exe from InstallShield
b) how to install firebord using InstallShield
I would be very appreciative! Thanks a lot, Matt
You should probably reword your question to get answers about how to execute an external program using command line parameters in an InstallShield script. Maybe the documentation would have enough info on that already.
Regarding the installation of Firebird, please have a look at this document which comes with the Firebird installation and shows all available switches for the Firebird setup executable. If you don't want the user to see that your program is installing Firebird you should probably use the /SP-, the /VERYSILENT and /SUPPRESSMSGBOXES switches. Other switches worth looking into are /NOICONS to suppress the creation of a program group in the start menu, and /COMPONENTS=... to install only what is absolutely necessary for your program to function.
Please note that installing Firebird is only a part of what you should do. For clear separation from other programs using Firebird you should create a new Firebird user account with password, and it's always a good idea to add an alias for your database to the aliases.conf file.