<p dir="ltr"><br /> On Nov 28, 2012 1:54 AM, "Tom Lane" <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > Alvaro Herrera <<a
href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>>writes:<br /> > > Peter Eisentraut
wrote:<br/> > >> There is already the PQconninfoOption.dispchar field for this purpose.<br /> ><br /> >
>I had the impression that that field would go away with this patch, but<br /> > > then again it might not be
worththe compatibility break. I find the<br /> > > dispchar thingy somewhat unsightly.<br /> ><br /> > It
isthat, without a doubt, but that API has been that way longer than<br /> > any of us have been working on the code.
I'mnot excited about changing<br /> > it just to have an allegedly-cleaner API. And we cannot have the field<br />
>simply "go away", because it's been exposed to applications for lo these<br /> > many years, and surely some of
themare using it. So in practice we'd<br /> > be maintaining both the old API and the new one.<br /> ><br />
>I think we should leave it as-is until there are more reasons to change<br /> > it than seem to be provided in
thisthread.<br /><p dir="ltr">I think removing that would be a really bad idea. I'm not sure anybody is actually
relyingon it, but it would also change the size of the struct and thus break things for anybody using those functions.
<pdir="ltr">If people prefer we remove the password classifier for the new function since it at least partially
duplicatesthat field we can certainly do that, but I think leaving it in allows those who write new code to use a
slightlyneater api, at pretty much no cost in maintenance for us. <p dir="ltr">/Magnus
