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.
> I have made the changes necessary to allow environment variables to be
> entered and expanded in file names. Two files had to be changed
> backend/commands/define.c and backend/utils/fmgr/dfmgr.c. Assuming you are
> interested in the change,
Well, that's a good question. Does anyone else have an opinion on
whether this would be a good/bad/indifferent feature? We've seen
problems in the past caused by depending on postmaster environment
variables (restart the postmaster with different environment than
usual, things mysteriously break). So I'm inclined to feel that adding
more dependence on them isn't such a hot idea. But I'm not going to
veto it if there's interest in the feature from other people.
> what is the proper way to build a patch file that
> contains the changes? I have never done this before.
"diff -c" against current sources, done so that the correct file
pathnames are visible in the diff output; that is, cd to top level
of distribution tree and do something like
diff -c src/backend/utils/fmgr/dfmgr.c.orig src/backend/utils/fmgr/dfmgr.c
Don't forget to include diffs for documentation updates, as well.
regards, tom lane
