> 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 mysterio
Tom Lane wrote:
> Jeffery Collins <[EMAIL PROTECTED]> writes:
> > 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
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. Cav
Jeffery Collins <[EMAIL PROTECTED]> 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 doe
Jeffery Collins wrote:
> I was wondering if anyone could help me with the following questions.
> They are all related to user defined types and functions.
>
> 1. Environment variables in function pathname. We would like to
> [...]
Create your SQL scripts that define the functions in a
