Обсуждение: Adminpack removal
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.
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.emaj@free.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. > > >
On Thu, 27 Jun 2024, 07:34 Philippe BEAUDOIN, <phb.emaj@free.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. The extension at first glance doesn't currently seem to depend on adminpack: it is not included in the control file as dependency, and has not been included as a dependency since the creation of that file. Where else would you expect us to search for dependencies? Kind regards, Matthias van de Meent
Le 27/06/2024 à 10:38, Matthias van de Meent a écrit : > On Thu, 27 Jun 2024, 07:34 Philippe BEAUDOIN, <phb.emaj@free.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. > The extension at first glance doesn't currently seem to depend on > adminpack: it is not included in the control file as dependency, and > has not been included as a dependency since the creation of that file. You are right. Even before the adminpack usage removal, the extension was not listed as prerequisite in the control file. In fact, I introduced a new E-Maj feature in the version of last automn, that used the adminpack extension in one specific case. But the user may not install adminpack. In such a case, the feature was limited and a warning message told the user why it reached the limitation. I was waiting for some feedbacks before possibly adding adminpack as a real prerequisite. > > Where else would you expect us to search for dependencies? The word "adminpack" can be found in the sql source file (sql/emaj--4.4.0.sql), and in 2 documentation source files (in docs/en/*.rst). The pg_file_unlink() function name can be found in the same sql source file. But, I understand that looking for simple strings in all types of files in a lot of repo is costly and may report a lot of noise. More broadly, my feeling is that just looking at public repositories is not enough. The Postgres features usage can be found in: - public tools, visible in repo (in github, gitlab and some other platforms) ; - softwares from commercial vendors, so in close source ; - and a huge number of applications developed in all organizations, and that are not public. So just looking in public repo covers probably less than 1% of the code. However, this may give a first idea, especialy if a feature use is already detected. In this "adminpack" case, it may be interesting to distinguish the pg_logdir_ls() function, which covers a very specific administration feature, and the other functions, which are of a general interest. It wouldn't be surprising that pg_logdir_ls() be really obsolete now that it is not used by pgAdmin anymore, and thus could be removed if nobody complains about that. May be the others functions could be directly integrated into the core (or left in adminpack, with the pgAdmin reference removed from the documentation). Kind Regards. Philippe.