We could decree that a contrib module's script should create a schema
and shove everything it makes into that schema. Then DROP SCHEMA CASCADE
is all you need to get rid of it. However, you'd probably end up having
to add this schema to your search path to use the module conveniently.
Got it fixed.
As it happens, there's an untsearch2.sql script in the contrib directory.
Removing the transaction block around it allowed it to kill all the dregs
from the 7.4.x database entries (on 8.0.1) and a subsequent tsearch2.sql
was then able to rebuild them.
I had to reinsert the columns
On Thu, Feb 03, 2005 at 06:44:55PM -0600, Karl Denninger wrote:
As it happens, there's an untsearch2.sql script in the contrib directory.
That reminds me: it would be useful if all contributed modules had
an unmodule.sql file. That would simplify reloading the module if
the definitions
On Thu, Feb 03, 2005 at 06:59:55PM -0700, Michael Fuhr wrote:
On Thu, Feb 03, 2005 at 06:44:55PM -0600, Karl Denninger wrote:
As it happens, there's an untsearch2.sql script in the contrib directory.
That reminds me: it would be useful if all contributed modules had
an unmodule.sql file.
Karl Denninger [EMAIL PROTECTED] writes:
I agree with this - what would be even better would be a way to create
'subclasses' for things like this, which could then be 'included' easily.
We could decree that a contrib module's script should create a schema
and shove everything it makes into that
On Thu, Feb 03, 2005 at 10:20:47PM -0500, Tom Lane wrote:
Karl Denninger [EMAIL PROTECTED] writes:
I agree with this - what would be even better would be a way to create
'subclasses' for things like this, which could then be 'included' easily.
We could decree that a contrib module's script
On Thu, 3 Feb 2005, Karl Denninger wrote:
On Thu, Feb 03, 2005 at 10:20:47PM -0500, Tom Lane wrote:
Karl Denninger [EMAIL PROTECTED] writes:
I agree with this - what would be even better would be a way to create
'subclasses' for things like this, which could then be 'included' easily.
We could
