I would like to use a shared library I produced from db2 queries.
My shared library depends on boost that, in my machine, is locate in /usr/local/lib.
When I try to run the queries using my functions I got errors: they dosn't work because db2 cannot find boost libraries i.e. cannot resolve the location of the libraries.
How to tell db2 where to locate the libraries path and which enviromnent variable s I should use?
I tried to ise userprofile and profile.env but without success.
# userprofile
LIBPATH=/usr/local/lib:LIBPATH
#profile.env
DB2ENVLIST='LIBPATH ..other stuf'
Let me see if I understand your question correctly. You have C or C++ external UDFs that depend on some other libraries. If so, I think you should set the DB2 registry variables, not your environment variables:
export LD_LIBRARY_PATH=/usr/local/lib:$LIBPATH # this must be in the global profile
db2set DB2LIBPATH=$LD_LIBRARY_PATH
db2set DB2ENVLIST="LD_LIBRARY_PATH otherstuff"
The LD_LIBRARY_PATH variable must be set in the environment for the instance owner user and the DB2 fenced user, because the external routines run under one of these two. Probably the best way to do it is to set /etc/profile. This should be done before executing the db2set commands.
After setting the registry variables using db2set you must restart the DB2 instance (db2stop force then db2start).
Related
I am currently trying to run some Stata code related to the WRDS database for my Ph.D. It is a postgres database requiring some configuration via ODBC. While isql connection via Terminal works, the command odbc list in Stata returns the following error:
The ODBC file libodbc.dylib could not be found on this system. Setting the unix LD_LIBRARY_PATH environment variable may correct this error.
I mainly followed the tutorial on https://gist.github.com/JonathanWillitts/7b5a519bd40dd730b98ce1ad75e859e8, trying to adapt it to the Postgres requirements for the Database via homebrew and psqlodbc. I assume the error comes from the variable export via Terminal that I use:
export LD_LIBRARY_PATH=/opt/homebrew/lib/ && /Applications/Stata/StataSE.app/Contents/MacOS/StataSE &
I have had success downloading WRDS data into R using the RPostgres package.
If you do not figure out how to download WRDS data directly into Stata, a possible workaround is to:
Use R and the RPostgres package, and download the data into R
Then export the data from R into Stata, see:
https://www.statmethods.net/input/exportingdata.html
https://datascienceplus.com/exporting-data-from-r/
I am happy to share R code for obtaining WRDS data. Let me know if this interest you and I can share my R code here.
In conf we added the following line:
shared_preload_libraries = 'passwordcheck'
After restart postgres, password check is supposed to take effect, and I can test by creating a simple password for the new role. My question is:
Is there any way to list preloaded (enabled) libraries, or show this lib has been successfully loaded?
You can examine the current setting of shared_preload_libraries to see which libraries were loaded at server start time. You can be certain that these libraries are loaded, because otherwise the server would have refused to start and stopped with an error message.
But there are many other ways to load an extension shared library into PostgreSQL, for example by calling C functions or using the LOAD statement. There is no way in PostgreSQL to determine all libraries that are currently loaded into your database backend process.
Trying to follow the directions for installing the MySQL ODBC driver.
When I try to run:
myodbc-installer -a -d -n "MySQL ODBC 8.0 Driver" -t "Driver=/usr/local/lib/libmyodbc8w.so"
It says:
[ERROR] SQLInstaller error 6: Unable to find component name
I've found a handful of cases of people reporting this same message, e.g., here and here. Yet there seems to be no resolution.
Noticing the slight variations in the -n name string for the various drivers, I wondered if perhaps the name was something subtly different and the documentation hadn't been updated. But I used a hex editor to look in /usr/local/lib/libmyodbc8w.so and the literal string "MySQL ODBC 8.0 Driver" is in it.
There may be some instances of a name mismatch causing the problem (e.g. in one of the linked-to cases, they use -n "MySQL" instead of the prescribed -n "MySQL ODBC 5.3" from the notes).
However...in my case it was a matter of not using sudo. The error message is not very helpful in indicating that the problem could be a matter of privileges! :-/ But at the very top of the linked instruction page it says (emphasis mine):
To install the driver from a tarball distribution (.tar.gz file), download the latest version of the driver for your operating system and follow these steps, substituting the appropriate file and directory names based on the package you download (some of the steps below might require superuser privileges)
What's going on is that unixodbc has system-wide odbcinst.ini and odbc.ini. It is stated that you should not be editing these files directly, but they are edited via an API that unixodbc provides. That API is called by the MySQL helper utility called myodbc-installer:
The error message is delivered by this print_installer_error() routine
...which is called from add_driver() when the routine SQLInstallDriverExW() returns false
(Note: unixodbc on most platforms provides the (W)ide Character version of SQLInstallDriverEx(), but myodbc-installer defines its own SQLInstallDriverExW() if it is not available via a shim.)
This API apparently doesn't have a way of saying it can't get the necessary privileges to the files (in /usr/local/etc or perhaps just in /etc). So myodbc-installer is just parroting what it got. Sigh.
EXPORT TO myFile.ixf OF ixf SELECT * FROM TABLE_NAME WHERE SSN='DATA' AND EMPLOYER_ID=DATA AND CREATED_TS='DATA'
I am using this statement to export a couple of rows. for privacy purposes DATA has been inserted where necessary. however the following error is produced. I have followed IBM's guide on export and feel like this should be correct but unsure exactly as to what is wrong. the error log is as follows
Error: DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=myFile;EXPORT TO ;JOIN, DRIVER=3.53.70
SQLState: 42601
ErrorCode: -104
As already remarked, you cannot directly run Db2-commands (such as import, export, load ... etc.) from plain SQL , as you are trying to do via JDBC.
Instead, if your Db2-server runs on Linux/Unix/Windows, you can either use a stored procedure, or (for any Db2-server operating system) you can use the command-line.
However, when you use stored-procedure SYSPROC.ADMIN_CMD for Db2-LUW, all file-names in stored-procedure parameters are relative to the Db2-server (and not your remote jdbc-client, if you are running remotely).
That means after a successful export via stored-procedure, if you really need the exported IXF file to be on your workstation then you must do file-transfer to your workstation using whatever tools you have for that purpose.
For example, this shows an export on Unix to an IXF file in /tmp on the Db2-server:
call sysproc.admin_cmd('EXPORT TO /tmp/myFile.ixf OF ixf SELECT * FROM user1.stk1 with ur') ;
If you don't want to use a stored procedure, you must use the command-line shell (for example on Windows, use db2ntcmd.bat , or on Unix use bash or ksh) and connect to the database in the shell and perform the export. This requires the workstation to have a Db2-client and also that the relevant database and node be first catalogued.
If you specify your Db2-version and the operating-system on which your Db2-server runs, then you will get more details.
Is it possible to create "DIRECTORY" object in Postgres?
If not can some help me with a solution how implement it on PostgreSQL.
Not the best option, but you could use:
COPY (select 1) TO PROGRAM 'mkdir --mode=777 -p /path/to/your/directory/'
Note that only the last part of directory get the permissions set in mode.
There is no equivalent concept to an "Oracle directory" in Postgres.
The alternatives depend on why the "Oracle directory" is needed.
If the directory is needed to read and write files on the database server, then this can be done through Generic File Access Functions. Access to those functions is restricted to superusers (details in the linked section of the manual). If regular users should be able to use them, the best thing would be to create wrapper functions and then grant execute on those functions to the users in question.
For security reasons, only directories inside the database cluster can be accessed.
But it's possible to create symlinks inside the data directory that point to directories outside the data directory. Access privileges on those directories need to be properly setup for the postgres operating system user (the one under which the postgres process is started)
If the directory is needed to access e.g. CSV files through Oracle's external tables, then there is no need for a "directory". The file FDW foreign data wrapper, can access files outside the data directory (provided access privileges have been setup correctly on the file system level).
The question doesn't even make sense really. PostgreSQL is a database management system. It doesn't have files and directories.
The closest parallel I can think of is schemas - see CREATE SCHEMA.
Now, if you want to use COPY to write output to the server's disk and want to create a directory to put that output in... then no, there's nothing like that. But you can use PL/Perlu or PL/Pythonu to do it easily enough.