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

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Jeffery Collins <collins(at)onyx-technologies(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Re: [GENERAL] Some questions on user defined types and functions.
Date: 2000-07-28 02:33:01
Message-ID: 3980F0DD.737B1D8D@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeffery Collins 2000-07-28 03:53:31 Re: Connection problem under extreme load.
Previous Message brianb-pggeneral 2000-07-28 02:26:36 Backup/dump of huge tables and performance

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-07-28 02:40:30 Re: Another TODO: insert/update...returning
Previous Message Bruce Momjian 2000-07-28 02:27:35 Re: Another TODO: insert/update...returning