Re: Some questions on user defined types and functions.

It would seem that it wouldn't break anyone's existing setup, since
you couldn't have an env variable in there anyway. (No one really
has a directory called $HOME, I hope!)

So, perhaps it could just be something in the documentation that
has a stern warning about watching your consistency. Caveat
hacker and all that.

On 26 Jul 2000, at 17:50, Tom Lane wrote:

> 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


--
Joel Burton, Director of Information Systems -*- jburton@scw.org
Support Center of Washington (www.scw.org)