Re: Re: [GENERAL] Some questions on user defined types and functions.

From: Jeffery Collins <collins(at)onyx-technologies(dot)com>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Re: [GENERAL] Some questions on user defined types and functions.
Date: 2000-07-28 04:30:50
Message-ID: 39810C7A.A2EDC4F@onyx-technologies.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Thomas Lockhart wrote:

> > 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

Feel free to change so that the envar must be leading. It is definitely easier
code with this restriction and definately faster.

If you want, I will make the change. If the restriction is desired, I can make
the code in database.c and my code common.

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Swan 2000-07-28 04:47:00 Re[2]: upgrade from 6.4 to 7.02 problem
Previous Message Jeffery Collins 2000-07-28 03:53:31 Re: Connection problem under extreme load.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-07-28 05:22:34 Re: Re: Another TODO: insert/update...returning
Previous Message Philip Warner 2000-07-28 02:40:30 Re: Another TODO: insert/update...returning