Re: Adminpack removal

I agree that removing adminpack was a bit of a surprise for me as
well. At first I assumed that it was just moved into the core to
accompany the file and directory *reading* functions, until I found
the release notes mentioning that now one of the users of adminpack
does not need it and so it is dropped.

The easy and currently supported-in-core way to do file manipulation
is using pl/pythonu or pl/perlu but I agree that it is an overkill if
all you need is a little bit of file manipulation.

Best Regards
Hannu

On Thu, Jun 27, 2024 at 7:34 AM Philippe BEAUDOIN <phb(dot)emaj(at)free(dot)fr> wrote:
>
> Hi,
>
> I have just tested PG17 beta1 with the E-Maj solution I maintain. The
> only issue I found is the removal of the adminpack contrib.
>
> In the emaj extension, which is the heart of the solution, and which is
> written in plpgsql, the code just uses the pg_file_unlink() function to
> automatically remove files produced by COPY TO statements when no rows
> have been written. In some specific use cases, it avoids the user to get
> a few interesting files among numerous empty files in a directory. I
> have found a workaround. That's a little bit ugly, but it works. So this
> is not blocking for me.
>
> FYI, the project's repo is on github (https://github.com/dalibo/emaj)
> which was supposed to be scanned to detect potential adminpack usages.
>
> Finally, I wouldn't be surprise if some other user projects or
> applications use adminpack as this is a simple way to get sql functions
> that write, rename or remove files.
>
> Regards.
>
>
>