Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. Please commit ASAP. Is I stated several times, I'll do the win32 as soon as I get a chance to. It's not a logger file issue, it's a *win32 stderr* problem. If you believe that a feature must support all systems, tablespace must be removed as well. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. How is logging typically handled on Windows? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Admin functions contrib
Peter Eisentraut wrote: Bruce Momjian wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. How is logging typically handled on Windows? It is done using the eventlog service (which is supported as replacement for syslog now) or in case of MSSQL as file logging. MSSQL in more detail: In eventlog only the most important MSSQL messages will appear (start/stop, PANIC), while the rest is done in logfiles (retrievable over client tools, rotatable using sp_cycle_errorlog) and may grow much larger than eventlog (which will receive messages from all apps/services). This handling is so throughout M$ apps, like webserver etc: fatals to eventlog, the rest to files. Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Admin functions contrib
It's better than no patch I think. /D -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Sat 7/31/2004 5:33 AM To: Dave Page Cc: Tom Lane; Andreas Pflug; PostgreSQL Patches Subject: Re: [PATCHES] Admin functions contrib Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. --- Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 29 July 2004 18:41 To: Andreas Pflug Cc: Bruce Momjian; PostgreSQL Patches; Dave Page Subject: Re: [PATCHES] Admin functions contrib Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Admin functions contrib
Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. I'm slightly worried that we might be painting ourselves into a corner, ie implementing functionality that will never work on Windows. Personally, of course, I won't care if it never works on Windows. But I suspect there are some out there who do care ;-). It might be better to wait till we're sure there's a reasonable implementation path for Windows. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Admin functions contrib
Tom Lane wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. I'm slightly worried that we might be painting ourselves into a corner, ie implementing functionality that will never work on Windows. Personally, of course, I won't care if it never works on Windows. But I suspect there are some out there who do care ;-). It might be better to wait till we're sure there's a reasonable implementation path for Windows. Actually, I believe the implementation I did first (having all processes append to the logfile themselves) would have worked for win32 too. As long as you don't impose linux-centric limitations on win32 implementations, there certainly *are* solutions to the problem. A very reasonable way would be to have the win32_signal_waiter thread not only wait for the child terminating, but also checking the pipe. This is certainly *the* recommended win32 way. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
This logging issue has drained a lot of time during feature freeze when we should be getting existing patches in and completed. I am willing to apply a perfect patch but I am not willing to spend anymore time on this than I have to. This is all something that shouldn't be happening during feature freeze. I realize this patch is important to Andreas but every patch is important to its author. We have done just fine without this functionality for years so I don't see the rush to get it in. You can say Win32 will make it more significant, but if it doesn't work on Win32 yet, the argument doesn't work. And I am not going to apply a patch with the promise that a more complete one is coming later. I am not saying I am going to reject the patch if it arrives but I am not but I am not going to be upset if it doesn't make it in until 7.6. --- Andreas Pflug wrote: Bruce Momjian wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. Please commit ASAP. Is I stated several times, I'll do the win32 as soon as I get a chance to. It's not a logger file issue, it's a *win32 stderr* problem. If you believe that a feature must support all systems, tablespace must be removed as well. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Admin functions contrib
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 29 July 2004 18:41 To: Andreas Pflug Cc: Bruce Momjian; PostgreSQL Patches; Dave Page Subject: Re: [PATCHES] Admin functions contrib Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Admin functions contrib
Dave Page wrote: As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. If you're curious what Bruce has seen, it was this: http://www.pse-consulting.de/pgadmin3/pgadmin3-serverlog.png The size functions will offer this: http://www.pse-consulting.de/pgadmin3/pgadmin3-tblspc-stat.png Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Admin functions contrib
Andreas Pflug wrote: Dave Page wrote: As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. If you're curious what Bruce has seen, it was this: http://www.pse-consulting.de/pgadmin3/pgadmin3-serverlog.png The size functions will offer this: http://www.pse-consulting.de/pgadmin3/pgadmin3-tblspc-stat.png Yep, that's what I saw. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Admin functions contrib
Dave Page wrote: Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Ouch, that is a powerful argument! The big problem is that we are designing features a month after feature freeze. Not that the ideas weren't around before feature freeze, but they are still not solid from a community agreement perspective. Let's get the logging working and then figure out what to do, OK? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. --- Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 29 July 2004 18:41 To: Andreas Pflug Cc: Bruce Momjian; PostgreSQL Patches; Dave Page Subject: Re: [PATCHES] Admin functions contrib Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: I talked to Tom about this today. First, I want to apologize for running you around in circles in this. I don't think we are giving it the attention it needs because of our schedule. I also think the functionality is drifting into the new features territory and this is also part of the delay you are seeing. I think you did a great thing by breaking the patch into two parts: one for logging, and the other for log reading and other stuff. The logging part is already in the patch queue. As for the function below, I first think the security issue brough up about them wasn't a valid concern because as I stated someone could just load the plperl server-side language and do anything to the OS. In fact this might be the best solution for you. Instead of trying to code read/write/rename/unlink and other functions into the backend as hardcoded, why not just have pgadmin load plperlu and as the super-user you have access to that functionality, and much more, especially with the new plperl in 7.5. In fact, your goal of modifying the postgresql.conf file is much more natural in perl than in the API you supplied, and probably more reliable. So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. What you're proposing is simply a nightmare. Actually, IMHO all functions should be *backend* code, not contrib code, even less arbitrary loadable language functions. Certainly an external package relying on a loadable language is quite the opposite, generating lots of support issues. It won't generate trust if pgadmin documentation advises install untrusted plperl to maintain your machine. Additionally, several of the functions are by no means new, but replacements, did you notice pg_xxx_size? I posted this stuff as contrib module to keep it off the feature freeze issue. If it still can't go there, it must stay an external module which will be distributed as pgadmin add-on. Reimplementing it as plperlu is crap. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
Andreas Pflug wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. What you're proposing is simply a nightmare. Actually, IMHO all functions should be *backend* code, not contrib code, even less arbitrary loadable language functions. Certainly an external package relying on a loadable language is quite the opposite, generating lots of support issues. It won't generate trust if pgadmin documentation advises install untrusted plperl to maintain your machine. Additionally, several of the functions are by no means new, but replacements, did you notice pg_xxx_size? I posted this stuff as contrib module to keep it off the feature freeze issue. If it still can't go there, it must stay an external module which will be distributed as pgadmin add-on. Reimplementing it as plperlu is crap. Well, if plperlu was always compiled by default we would be OK. If it isn't then you are right it would be a problem. I see the --with-perl option to configure so you are right it might be a problem. Basically I think we are converging on an answer that we can't do any of this for 7.5. The scope has gone way beyond what we had at feature freeze, and we can't even get it to work on Win32, which was one of the big goals for easier Win32 administration, so I think we should just shelve all this and get it right for 7.6 when we have time to address this. I have added this to the TODO list: * Allow server logs to be read using SQL commands * Allow server configuration parameters to be modified remotetly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: Basically I think we are converging on an answer that we can't do any of this for 7.5. If it's not going into the distribution as contrib or core, I'll package that as additional admin pack. I'm quite sure I can convince the win32 installer packager guys to include that as default-on option as soon as I'm able to prove them how it's working. The scope has gone way beyond what we had at feature freeze, and we can't even get it to work on Win32, ??? The functions will work for win32, are you talking about logging? The win32 log issue isn't a serverlog rotation issue, as I stated also the current stderr output is affected! I'd clearly see that as a fix, whilst it might be more than 10 lines of code. I'll try to fix that tomorrow. The very log_destination=file and rotation code will be more or less the same as for ***x. I have added this to the TODO list: * Allow server logs to be read using SQL commands * Allow server configuration parameters to be modified remotetly This is desirable in any case. But until 7.6 will be around, 1-1.5 years and ???,000 installations will happen. Since the functionality is available now or will be available VSN (certainly before 7.5 release), there's no good reason suppress it. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. I think that developing with plperl for a few months would be a good path, because then you would have some actual field experience under your belt to justify the specific design of the contrib or core backend functions you want. Right now they look mighty scattershot. It won't generate trust if pgadmin documentation advises install untrusted plperl to maintain your machine. Nonsense. You are already expecting these people to give you superuser access, no? They had better trust you already. (Actually, you wouldn't even have to ask them --- you could just create plperlu for yourself --- but I suppose that would seem impolite.) I posted this stuff as contrib module to keep it off the feature freeze issue. Contrib does not have an exception for the feature freeze rule. It's a little looser maybe but that doesn't mean we'll accept an entire new module after freeze. Reimplementing it as plperlu is crap. I'm sorry you feel that way. It seemed like a fairly attractive alternative to me, especially for early development. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
I talked to Tom about this today. First, I want to apologize for running you around in circles in this. I don't think we are giving it the attention it needs because of our schedule. I also think the functionality is drifting into the new features territory and this is also part of the delay you are seeing. I think you did a great thing by breaking the patch into two parts: one for logging, and the other for log reading and other stuff. The logging part is already in the patch queue. As for the function below, I first think the security issue brough up about them wasn't a valid concern because as I stated someone could just load the plperl server-side language and do anything to the OS. In fact this might be the best solution for you. Instead of trying to code read/write/rename/unlink and other functions into the backend as hardcoded, why not just have pgadmin load plperlu and as the super-user you have access to that functionality, and much more, especially with the new plperl in 7.5. In fact, your goal of modifying the postgresql.conf file is much more natural in perl than in the API you supplied, and probably more reliable. So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. --- Andreas Pflug wrote: These files add administrative functions to pgsql 7.5. All are used by pgAdmin3 or will be used in the near future if available. This is meant as contrib module, whilst IMHO all these functions should be integrated into the backend. Included are functions to log file access These where previously posted together with the logger subprocess patch and might get committed to the backend code. misc. send SIGHUP to postmaster generic file access functions These are more restrictive than the previously posted: Write access is necessary for files to rename and unlink, and paths are restricted to PGDATA and the logdir. size functions These are 7.5 replacements for dbsize. Regards, Andreas subdir = contrib/admin top_builddir = ../.. include $(top_builddir)/src/Makefile.global MODULE_big = admin DATA_built = admin.sql DOCS = README.admin OBJS = size.o genfile.o misc.o include $(top_srcdir)/contrib/contrib-global.mk /* ** * Administrative functions * * */ /* database object size functions (admin.c) */ CREATE FUNCTION pg_tablespace_size(oid) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_tablespace_size' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_database_size(oid) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_database_size' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_relation_size(oid) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_relation_size' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_size_pretty(bigint) RETURNS text AS 'MODULE_PATHNAME', 'pg_size_pretty' LANGUAGE C STABLE STRICT; /* generic file access functions (genfile.c) */ CREATE FUNCTION pg_file_stat(text) RETURNS record AS 'MODULE_PATHNAME', 'pg_file_stat' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_length(text) RETURNS bigint AS 'SELECT len FROM pg_file_stat($1) AS s(len int8, c timestamp, a timestamp, m timestamp, i bool)' LANGUAGE SQL VOLATILE STRICT; CREATE FUNCTION pg_file_read(text, bigint, bigint) RETURNS text AS 'MODULE_PATHNAME', 'pg_file_read' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_write(text, text, bool) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_file_write' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_rename(text, text, text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_file_rename' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_unlink(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_file_unlink' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_rename(text, text) RETURNS bool AS 'SELECT pg_file_rename($1, $2, NULL); ' LANGUAGE SQL VOLATILE STRICT; CREATE FUNCTION pg_dir_ls(text, bool) RETURNS setof text AS 'MODULE_PATHNAME', 'pg_dir_ls' LANGUAGE C VOLATILE STRICT; /* Miscellaneous functions (misc.c) */ CREATE FUNCTION pg_reload_conf() RETURNS int4 AS 'MODULE_PATHNAME', 'pg_reload_conf' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_logfile_rotate() RETURNS bool AS 'MODULE_PATHNAME', 'pg_logfile_rotate' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_logdir_ls() RETURNS setof record AS 'MODULE_PATHNAME', 'pg_logdir_ls' LANGUAGE C VOLATILE STRICT; CREATE VIEW pg_logdir_ls AS SELECT * FROM pg_logdir_ls() AS A (filetime timestamp, pid int4, filename text); Misc functions for administrative purposes
