From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bear Giles <bear(at)coyotesong(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: user types API wish list |
Date: | 2002-01-18 20:16:39 |
Message-ID: | 9807.1011384999@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bear Giles <bear(at)coyotesong(dot)com> writes:
> Based on my experience with the 7.1.3 user defined type API, here are
> several wishlist items. (They don't seem to be in 7.2b4 either.)
> 1) load/unload functions
> But more importantly, there's no way to free resources when the
> database shuts down or loads the shared library.
You can add an on_shmem_exit or on_proc_exit callback, though I agree
this doesn't cover the scenario of a forcible LOAD replacing an existing
copy of your shlib.
> It should be possible for a user-defined type to define itself,
> perhaps via a "bootstrap" procedure in the structure mentioned
> above. The bootstrap procedure could use SPI calls to define
> its own types, functions, operators and secondary indexes.
> All but the last item can be done by a SQL script, of course,
> but this provides a cleaner mechanism for complex packages.
Mph. I think the script approach is better, mainly because it
seems more configurable for mere-mortal end users. Stuffing things
down into C code doesn't make life easier for anyone.
> The final wishlist item, which may not be doable, is to have
> some context for the query. I know that the fcinfo structure
> does have a "context" field, but what I would really like to
> have is a clean way to determine:
> 1) the current database
There's a global variable to tell you that.
> 2) the target relation, or NULL if it's a freestanding select clause.
I do not understand what this means. What is the "target" of
SELECT ... FROM a JOIN b ?
> The purpose is to allow the user-defined functions to pull out
> metadata maintained elsewhere. E.g., I might define a catalogue
> containing public encryption encryption keys to use when writing
> data into certain tables. My encryption routines could pull this
> information out of the database with SPI... if I knew the name of
> the table that was the target of the insert or update.
This strikes me as broken by design. Why should the datatype depend on
the location in which it is stored? What happens if the intended target
is diverted by a rule or trigger; does that invalidate what you did?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Murray Prior Hobbs | 2002-01-18 20:17:31 | Re: pltlc and pltlcu problems |
Previous Message | Bruce Momjian | 2002-01-18 20:12:25 | Re: Confusing terminology |