Jeffery Collins <collins@onyx-technologies.com> writes:
> like the following syntax to work:
> CREATE FUNCTION myfunc(mytype) RETURNS text AS
> '$HOME/lib/libmyso.so' LANGUAGE 'c':
> and have the environment variable $HOME "lazy" evaluated. I
> have looked at the fmgr code and this doesn't look too difficult to add
> as long as I could get the $HOME past the parser.
The parser doesn't know a thing about that, it's just seeing a string
literal. I think hacking in dfmgr.c would be sufficient. Whether it's
a good idea is another question --- you realize you'd be dealing with
postmaster environment variables, right, not those of the connected
user? The way we handle this in the distribution is by substituting
appropriate strings into a script before it's handed to psql; see the
regression tests directory for examples.
> 3. fid assignment - Basically the same question as above but with
> functions instead of types. If there is an index that uses a function,
> it appears that you can't drop and re-create the function without
> blowing away the index definition.
I think it would be a really bad idea to allow recycling of type and
function OIDs for what might be completely incompatible objects. But
something that's been on the TODO list for a while is to create an ALTER
FUNCTION command that would replace the body of an existing function
without changing the declared signature (parameters and return type).
That seems relatively safe, and it'd be awfully handy. Want to have a
go at it?
regards, tom lane
PS: you do realize that revising the function on which an index is
based probably renders the index useless anyway? Unless you can
guarantee that none of the stored values change...