Re: [PATCHES] createdb/dropdb fixes

On 1999-12-14, Thomas Lockhart mentioned:

> That seems to be a bit heavy handed; why bother disallowing things in
> the backend because some (small number of) shell-based tools have
> trouble as clients? I'd prefer filtering that at the client end, and

It's really about statements like this:
snprintf(buf, sizeof(buf), "rm -rf '%s'", path);

There is no way around disallowing single-quotes unless you double quote
the argument and be very careful with the escaping. Of course this
particular case might as well use unlink(), but there is a recursive copy
of the template1 dir which would take a little more work (opendir(),
etc.). At that point we could lift that restriction.

> permissions. I haven't looked at the code in a long time, but was
> thinking about recoding ACLs as a two-field type to enforce an
> unambigous interpretation of the two fields. Interested??

I've been puzzled about this for a long time, is there a reason this is
stored as an array at all? Why not use tuples likeaclperm        char?aclrelation    oidaclentity    oid    /* user or
groupsysid */aclisgroup    bool    /* is it a user or group? */
 

And then it looks like this:
aclperm|aclrel|acluser|aclisgroup
-------+------+-------+----------
R      |177777|    100|f
W      |177777|    100|f
R      |177777|    120|f
R      |188888|      5|t

That's much cleaner. GRANT and REVOKE would be reduced to simple
insert/delete equivalents. I'm not sure how the actual authentication code
would like that overheadwise, though.

A related issue is pg_group, which I'm currently working on. Those arrays
are killing me. A simple user/group associating relation would be much
nicer.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden