Fixes for upstream

minor cleanups which supposed not to change logic, but
make code cleaner.
Let me revert the commit as it not clear to me is there any functional
behavior bound to it ( which is a defect by itself ).

-kofemann
/** caffeinated mutations of the core personality */

On Mon, Sep 15, 2014 at 12:25 AM, Dave Cramer <notifications@github.com>
wrote:

> In org/postgresql/core/v2/SimpleParameterList.java:
>
> > @@ -178,6 +178,6 @@ public void setBinaryParameter(int index, byte[] value, int oid) {
> >       * nb: we explicitly say "new String" to avoid interning giving us an object that
> >       * might be the same (by identity) as a String elsewhere.
> >       */
> > -    private final static String NULL_OBJECT = new String("NULL");
> > +    private final static String NULL_OBJECT = "NULL";
>
> Actually I think I prefer to use the generic Object. as per v3 code does.
> Dave Cramer
> … <#1487645b4bcdf22b_>
> On 14 September 2014 13:47, Sehrope Sarkuni <notifications@github.com>
> wrote: In org/postgresql/core/v2/SimpleParameterList.java: > @@ -178,6
> +178,6 @@ public void setBinaryParameter(int index, byte[] value, int oid)
> { > * nb: we explicitly say "new String" to avoid interning giving us an
> object that > * might be the same (by identity) as a String elsewhere. > */
> > - private final static String NULL_OBJECT = new String("NULL"); > +
> private final static String NULL_OBJECT = "NULL"; No the compiler would
> keep the new String("NULL") and explicitly create a new object reference
> for it. That way it'd be different than any interned reference to "NULL". I
> was wondering why this was done with a String rather than just a generic
> Object and it looks like that's what the v3 code does <
> https://github.com/pgjdbc/pgjdbc/blob/master/org/postgresql/core/v3/SimpleParameterList.java#L377>
> . I think the correct solution here is to change it to a generic Object and
> get rid of the comment though some other pieces have to change to
> accommodate that. The NULL_OBJECT is referenced when being set via
> setNull(...) and subsequently in the toString(int index) method. The latter
> handles it via the explicit == comparison though it'd work equally well
> with just toString() as it'd still be "NULL". Somewhat related, I'm not
> sure where that method is used for as it's not referenced in that class
> itself. Changing to a generic Object would break line 147 where the v2
> String value is being sent as a String "as is". A similar if statement
> would be needed there to send "NULL" instead. Maybe the toString(int index)
> method was meant to be called here as that would handle the NULL case
> (though the "?" for missing params doesn't make sense so that probably
> won't work). So in summary, skimming it so far I don't think anything will
> break by changing it to just "NULL", I just think it's really confusing. If
> we're going to touch that piece then might as well have it make sense. —
> Reply to this email directly or view it on GitHub <
> https://github.com/pgjdbc/pgjdbc/pull/184/files#r17521267>.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/pgjdbc/pgjdbc/pull/184/files#r17523088>.
>