Re: Some questions on user defined types and functions.
От | Joel Burton |
---|---|
Тема | Re: Some questions on user defined types and functions. |
Дата | |
Msg-id | 397F31F0.20445.B810F9@localhost обсуждение исходный текст |
Ответ на | Re: Some questions on user defined types and functions. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
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)
В списке pgsql-general по дате отправления: