]> granicus.if.org Git - postgresql/commit
This is the second time I've answered this exact same problem in two
authorBruce Momjian <bruce@momjian.us>
Fri, 12 May 2000 18:51:59 +0000 (18:51 +0000)
committerBruce Momjian <bruce@momjian.us>
Fri, 12 May 2000 18:51:59 +0000 (18:51 +0000)
commita28f1177901506aa32aafda987fc643dfefcbb8b
treea60909186cfa97d7a6b3c357c287c478064f969a
parent5e02f6b6acb9f7ba6e166c9dd6e7eb53bad01c7e
This is the second time I've answered this exact same problem in two
days.  It seems to be a FAQ, and I think I know why. When creating a 'c'
language function, CREATE FUNCTION is fed the shared object filename,
and seems to succeed. Only when trying to use the function is an error
thrown, by which time the coder thinks something's wrong with executing
the code, not with loading it.

I think I once saw it proposed to load shared objects at function creation
time, but that idea was shot down on the grounds of resident memory bloat,
ISTR. Here's a patch for a compromise: all it does is stat() the file,
just like the loader code does, so that the errors caused by non existent
files, and no directory 'x' permissions (the most common ones, it seems),
get caught while the developer is still thinking about code loading. It
doesn't catch all errors (like the code not being readable by the postgres
user) but seems to catch the most common, without actually opening the file.

What do you think?

Ross
src/backend/commands/define.c