Обсуждение: [HACKERS] Updated TODO list
I have updated TODO on the www page and the TODO/HISTORY files in the distribution for the 6.1 release. Let me know if there are any needed changes. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
ADMIN * Allow international error message support and add error codes The JDBC driver already has the international error message support. All it needs are some translations of the errors.properties file. It would be easy to add error codes to it. TYPES * Large objectso Fix large object mapping scheme, own typeid or reltype(Peter)o Allow large text type to use large objects(Peter) I hope to these two done for 6.6 o Not to stuff everything as files in a single directory, hash dirso Allow large object vacuuming Do you mean vacuuming within a large objects table, or removing orphaned ones? A solution for orphaning is in contrib, although it still needs some work. On the JDBC front, I'm planning for 6.6: * Array support * Large Object Stream support * More JDBC2 API implemented But the big one will be to get the driver to use the current protocol. Up until now, it's been using the 6.3 backend protocol. Now that the current driver supports JDBC2, I want to get it up to date. This will mean that the 6.6 driver will not be backward compatible with earlier backends (I can't remember which one started using the current protocol). The 6.5 driver does support 6.3 and 6.4.x backends. Peter -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council.
> ADMIN > > * Allow international error message support and add error codes > > The JDBC driver already has the international error message support. All > it needs are some translations of the errors.properties file. > > It would be easy to add error codes to it. Good. I think Vadim wasn't codes from the backend for scripts and stuff. > > TYPES > > * Large objects > o Fix large object mapping scheme, own typeid or reltype(Peter) > o Allow large text type to use large objects(Peter) > > I hope to these two done for 6.6 Good. I can help too. > > o Not to stuff everything as files in a single directory, hash > dirs > o Allow large object vacuuming > Do you mean vacuuming within a large objects table, or removing orphaned > ones? Tom Lane says you can get multiple versions of a large object in the file, and there is no way to remove them. > A solution for orphaning is in contrib, although it still needs some > work. > > On the JDBC front, I'm planning for 6.6: > > * Array support > * Large Object Stream support > * More JDBC2 API implemented > > But the big one will be to get the driver to use the current protocol. > Up until now, it's been using the 6.3 backend protocol. Now that the > current driver supports JDBC2, I want to get it up to date. Cool. > This will mean that the 6.6 driver will not be backward compatible with > earlier backends (I can't remember which one started using the current > protocol). The 6.5 driver does support 6.3 and 6.4.x backends. That is not a problem. We have given them enough releases that will work with the new driver. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > > >> DB admin has no business knowing other's passwords. > The current security > > > >> scheme is seriously flawed. > > > > > > > But it is the db passwords, not the Unix passwords. > > > > > > I think the original point was that some people use the > same or related > > > passwords for psql as for their login password. > > > > > > Nonetheless, since we have no equivalent of "passwd" that > would let a > > > db user change his db password for himself, it's a little silly to > > > talk about hiding db passwords from the admin who puts them in. > > > > > > If this is a concern, we'd need to add both encrypted storage of > > > passwords and a remote-password-change feature. > > > > Doing the random salt over the wire would still be a problem. > > And I don't like password's at all. Well, up to now the bare > PostgreSQL doesn't need anything else. But would it really > hurt to use ssl in the case someone needs security? I don't > know exactly, but the authorized keys might reside in a new > system catalog. So such a secure installation can live with a > wide open hba.conf and who can be who is controlled by > pg_authorizedkeys then. > > As a side effect, all communication between the backend and > the client would be crypted, so no wire listener could see > anything :-) I've actually been using this on and off for a while. (I did some changes to libpq some time back, so it no longer used fdopen() to access thins - in preparation of SSL patches). Though not a complete implementation - just that "if client certificate is trusted, then let'em in as whatever user they say". But it shouldn't be too hard to finish off. I'll try to get around to fix those patches up. The client-side implementation was really ugly, and not at all "generic" (only worked in my situation). Server-side was more generic. I'll try to fix the client-side there.. //Magnus