Обсуждение: [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