The only functions here all take a filesystem path which your database should definitely not have access to - why would you upload files/store PDFs on a database server!!?
These functions to be able to get the title or modification time of a PDF are also just not that useful.
I don't really understand this question. You can put data where you like. There are no "database servers". These aren't whole toys, take them or leave them. They're made of Lego bricks, and so you can change them.
> COPY naming a file or command is only allowed to database superusers or users who are granted one of the roles pg_read_server_files, pg_write_server_files, or pg_execute_server_program, since it allows reading or writing any file or running a program that the server has privileges to access.
From the documentation:
> Creating a pdf type, by casting either text path or bytea blob.
With the example: SELECT ''::bytea::pdf;
So it's convenient to use the path to test quickly, but you can use anything in PostgreSQL which return (or can be convert) a bytea
Not every object in a database needs to be ready for public consumption. Some of it's there for processing, for certain use cases.
In the second pass I made `pdf` a type.
Some early BLOB implementations had performance problems, which is where this notion that "you shouldn't store files in BLOBs" seems to come from. But modern DBMSes have fast BLOBs, especially if used properly through their streaming API (don't materialize the entire file in memory!).
We have a system in production that stores millions of files in BLOBs, some of them reaching multi-GB sizes, being accessed across the globe (a big enterprise company) by thousands of engineers, and never had performance problems with BLOBs.