I want to restore a blob entry to the file system as a file.
How can I do that with PostgreSQL on Linux?
Could you direct me towards an appropriate solution(s)?
Thanks in advance.
See this section 32.3.3 of the PostgreSQL docs on Client Interfaces for how to use the lo_export function.
You can use my pgsql-fio extension that provide basic file system functions.
Related
Can you help me understand if file_fdw allows to connect and read from FTP ? How can that be done?
file_fdw, starting in version 10, supports PROGRAM. So if you can write a program (or use existing programs) to read from ftp, you can hook file_fdw up to it.
No, file_fdw can only access files local on the database server machine.
Perhaps COPY ... FROM PROGRAM is what you need:
COPY tab
FROM PROGRAM 'curl ftp://server.org/file';
But this copies the data into a database table.
In OTN I am using these instructions to "try" and configure GoldenGate with a MSSQL Source DB to an Oracle12c Target DB
http://www.oracle.com/technetwork/articles/datawarehouse/oracle-sqlserver-goldengate-460262.html
Replicating Transactions Between Microsoft SQL Server and Oracle Database Using Oracle GoldenGate
Everything goes okay up till the command:
GGSCI (MSSQL) 2> ADD TRANDATA HRSCHEMA.EMP
Where I get the error:
ERROR OGG-05263 No GGSCHEMA clause was specified in the GLOBALS file. Please specify a GGSCHEMA shema name.
I searched and saw that currently there was no "GLOBALS" file. So I created one:
F:\GG\dirprm\globals.prm
And added one line:
GGSCHEMA hrschema
That did not help.
Still getting the same error.
Any suggestions?
Are there GoldenGate Environment variables that I need to have??
Thank-you in advace for your help.
I got the answer from Oracle Support:
The GLOBALS file should be in the main installation folder. Please remove the same from the dirprm file.
Also the GLOBALS file does not have extension. I could see that you have mentioned it as GLOBALS.prm
Made those changes and it works!
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.
I have been looking everywhere (google, stackoverflow, etc.) for some documentation on how to use the PostgreSQL pg_read_binary_file() function.
The only meaningful thing I can find is this page in the official documentation.
Every time I try to use this function I get an error.
For example:
SELECT pg_read_binary_file('/some/path/and/file.gif');
ERROR: absolute path not allowed
or
SELECT pg_read_binary_file('file.gif');
ERROR: could not stat file "file.gif": No such file or directory
Do I need to have my file in a specific directory for Postgres to have access to it? If so what directory?
If it matters, the reason I am looking at this function is because I am trying to insert a file into the database without doing crazy things.
As stated by #a_horse_with_no_name and #guedes the solution is to ensure that the file being uploaded is on the server in the PGDATA directory.
The postgres documentation does state the file location as a requirement.
Additionally, I made a symlink from another directory to the PGDATA directory so that I would not disturb any of the postgres data structure. This seems to be working well and I don't have to do any of the above crazy things.
We have the "coverity" tool setup and are trying to find a way to backup the database to a file, it uses I believe PostgreSQL.
How can we do this, is it using its own independent installation of PostgreSQL?
Even better answer..
cov-admin-db backup c:/mybackupfile
When you installed Coverity Integrity Manager, it asked you if you want it to install and manage a PostgreSQL instance or if you want to connect to your own existing PostgreSQL instance that you then have to manage.
If you chose the former, then you would use the provided cov-admin-db command.
If you chose the latter then presumably you already do regular back-ups of your databases with *pg_dump*, you should do the same for the Coverity database.
Without knowing which of the two you chose, it's not clear which of the two answers already given is correct.
You can check which option you chose by looking in the file /config/system.properties - if the first line is "*embedded_db=true*" then use the cov-admin-db command which is documented in the manual as well as in its own --help option.
If it does use PostgreSQL, then there should be a pg_dump utility somewhere in the PostgreSQL installation.
Taking backups using pg_dump is very well explained in the manual:
http://www.postgresql.org/docs/current/static/backup-dump.html
http://www.postgresql.org/docs/current/static/app-pgdump.html