Re: Re: [GENERAL] Some questions on user defined types and functions.
От | Thomas Lockhart |
---|---|
Тема | Re: Re: [GENERAL] Some questions on user defined types and functions. |
Дата | |
Msg-id | 3980F0DD.737B1D8D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [GENERAL] Some questions on user defined types and functions. (Jeffery Collins <collins@onyx-technologies.com>) |
Список | pgsql-hackers |
> I moved the discussion from General to Hackers, as I am getting into actual > code changes now. I hope this is appropriate. Yup. > I'm not exactly sure which code you are referring to. I did see the > following places where environment variables in paths are expanded: ... > backend/utils/misc/database.c: > This code is only applicable to finding the path to the database > directory. It has a hardwired 'base' in the expanded pathname. Also only > environment variables in the beginning of the path are supported. This is the one I was thinking of. The "leading envar" is pretty unambiguous; allowing them farther into the string will restrict paths from having a dollar sign (not terribly important, but it is an obscure restriction). Also, and probably more important, by requiring that the envar be in the first position it is a simple one-byte comparison to see if any expansion *may* need to be done. So the performance is not affected at all if no environment variable is used. > If y'all want the code, here are the diffs. The are from 7.0.2. I made, > what I think, are the appropriate changes to the documentation. I do not > have a way to build the documentation so I can't see how my changes actually > look - I hope they are appropriately formatted. Thanks. Shall we tweak it to support the same conventions as for the other cases (leading envar only)? It will remove any possible objection regarding efficiency, and it will conform to the other usages (btw, the "hardwired 'base/' in the database.c example could/should be considered a security feature since it requires a well-formed directory structure). - Thomas
В списке pgsql-hackers по дате отправления: