7.2 - changed array_out() - quotes vs no quotes - Mailing list pgsql-hackers
From | David Gould |
---|---|
Subject | 7.2 - changed array_out() - quotes vs no quotes |
Date | |
Msg-id | 20020207165939.A25347@crown.corp.nextbus.com Whole thread Raw |
Responses |
Re: 7.2 - changed array_out() - quotes vs no quotes
|
List | pgsql-hackers |
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 areneeded 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 documentationabout 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@nextbus.com (or davidg@dnai.com) Criminal: A person with predatory instincts who has not sufficient capital to form a corporation. - Howard Scott
pgsql-hackers by date: