The R Procedural Language in Postgres FAQ

How do I start the Postgres server so that it knows about R? How do I register an existing R function as a Postgres function? How do I add a converter for a Postgres type not alread implemented? Why do you write in noweb? How can I work with the source code given that it is in noweb? I re-installed the the REmbeddedPostgres package to a different directory, and now I get weird error messages about things that used to work. What's the problem? When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library. Use the uninstall.sql script in the scripts/ directory. Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.
How do I register an existing R function as a Postgres function? How do I add a converter for a Postgres type not alread implemented? Why do you write in noweb? How can I work with the source code given that it is in noweb? I re-installed the the REmbeddedPostgres package to a different directory, and now I get weird error messages about things that used to work. What's the problem? When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library. Use the uninstall.sql script in the scripts/ directory. Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.
How do I add a converter for a Postgres type not alread implemented? Why do you write in noweb? How can I work with the source code given that it is in noweb? I re-installed the the REmbeddedPostgres package to a different directory, and now I get weird error messages about things that used to work. What's the problem? When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library. Use the uninstall.sql script in the scripts/ directory. Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.
Why do you write in noweb? How can I work with the source code given that it is in noweb? I re-installed the the REmbeddedPostgres package to a different directory, and now I get weird error messages about things that used to work. What's the problem? When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library. Use the uninstall.sql script in the scripts/ directory. Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.
How can I work with the source code given that it is in noweb? I re-installed the the REmbeddedPostgres package to a different directory, and now I get weird error messages about things that used to work. What's the problem? When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library. Use the uninstall.sql script in the scripts/ directory. Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.
I re-installed the the REmbeddedPostgres package to a different directory, and now I get weird error messages about things that used to work. What's the problem? When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library. Use the uninstall.sql script in the scripts/ directory. Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.: When you re-installed the package and the associated C library, you may not have reinstalled the Postgres functions in the databases. These still point to the .so that was initially specified in the AS clause of the function definitions. If this library is still there, bad things happen as you are now mixing two different versions of the .so library.
Use the uninstall.sql script in the scripts/ directory.
Record-wise functions seem to be slow. What's the problem? Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.: Unfortunately, in versions of Postgres earlier than 7.1, we have to locate the R function to call for each record. This involves evaluating the AS clause that defines the function or simply get()'ing the function from within the R search path. This slows things down as it should be done once for each query, rather than once per-record. We can use this once-per-query approach in version 7.1 of Postgres and this will greatly improve performance.

How do remove an aggregator function already defined?

   DROP AGGREGATOR name basetype

Last modified: Wed Apr 11 20:00:39 EDT 2001