7.2 - changed array_out() - quotes vs no quotes

Somewhere after 7.2b2 (it looks like for 7.2b4) a change was made to
array_out() in:

src/backend/utils/adt/arrayfuncs.c,v 1.72 2001 /11/29 21:02:41 tgl

"Fix array_out's failure to backslash backslashes, per bug# 524.
Also, remove brain-dead rule that double quotes are needed if
and only if the datatype is pass-by-reference; neither direction
of the implication holds water. Instead, examine the actual data
string to see if it contains any characters that force us to quote
it. Add some documentation about quoting of array values, which was
previously explained nowhere AFAICT."

The older code quoted any "pass by ref" types, ie varlena's as opposed to
ints or floats. Which was perhaps clumsy, but at least was predictable.
That is, if it was a char or text type you could assume it was quoted, eg

{ "foo", "bar", "foo bar", "foo.bar", "foo,bar" }.

The new code goes to the trouble of scanning the string for embedded
commas, curlys, backslashes and whitespace. If it finds some it arranges
for quotes, otherwise it suppresses the quotes anywhere it is possible
not to use them.

There is now no easy way for a client to know what the output will look
like as it now depends on the specific data values, eg:

{ foo, bar, "foo bar", foo.bar, "foo,bar", "foo\"bar" }

This pretty much breaks any client that does not have a scanner at least
as intelligent as the array_in() scanner. Which includes most perl
programs, and pretty much all shell scripts using psql and arrays.

Since Jdbc did not support arrays well until very recently, I suspect it
broke a few hand written java array scanners too. It did ours.

Finally, I simply don't see the need for this change. There is no pressing
world shortage of double-quote characters, so there seems little reason to
conserve them. Especially at the cost of breaking existing clients and
complicating future client code (exercise: write a shell function to
scan the new style of array result correctly).

I view this change as a bug and would like to see it backed out.

<rant>

We monitor the hackers list, test with most betas, read the release
notes carefully. And were completely blindsided when our production apps
fell over after we upgraded from 7.2b2 to the release. Grrrr....

So right now we have reverted to our previous version and deferred our
our upgrade until we decide whether to patch out this change (and maintain
another patch) or to rewrite some of our client code (at least we have
source so we have this option, some don't).

I would really like to hear that I have persuaded you that it is a bug
and will be fixed in a future release.

Alternatively that you plan not to slipstream client visible formatting
changes into late betas. Especially without any mention in the release
notes.

I really wish one could upgrade from release to release of postgres without
a db reload, or rewriting client software, and especially not without
both.

Grrrr....

Grrrr....

</rant>

Regards

-dg

--
David Gould dg(at)nextbus(dot)com (or davidg(at)dnai(dot)com)
Criminal: A person with predatory instincts who has not sufficient capital
to form a corporation. - Howard Scott