Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

pgsql-hackers by date

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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group