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 like
aclperm char?
aclrelation oid
aclentity oid /* user or group sysid */
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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden