Re: trouble caused by change in 7.3 handling of '' in - Mailing list pgsql-general

There is a similar problem with arrays (see examples below). Some comments:
sendmail was written with a philosophy of "accept as much as possible,
generate only that which is strictly standards compliant". A laudable goal
but one which has allowed people to write all sorts of crappy mail user
agents that "worked". The resulting proliferation of broken MUAs has led to
the requirement to add "compatibility" hacks not only to sendmail but to most
other mail transport programs as well. Fortunately many MTAs have
configuration options that allow you to turn these "features" on or off.

From that perspective it is preferable to get people to write
specification-compliant code. But lest anyone get too smug I would point out
that www.postgresql.org utterly fails the w3c html validator test. So much
for adherance to standards.

But what if there aren't standards...

PostgreSQL has many extensions (arrays for one) which are seemingly not fully
thought out. I can determine the current behavior by experiment and reading
the source code but I cannot find a specification for the feature to tell me
if the current release is working as the developers ultimately intend. I
don't want to code to some behavior that I've discovered but which is not
documented - down that road is only misery.

An example: I have asked on these groups several times about arrays and have
gotten no replies. Currently if I ask for an element beyond the end of an
array it will return a null. If I could find that to be the documented
specification for array behavior I could start working on my app. As it is I
can not because I may be creating code that will break with the next release
of PostgreSQL.

I am all the more concerned since with version 7.3 the interpretation of
arrays has become non-consistent. A skipped element in a text array gets a
default entry of '' while a skipped element in an int array, which used to
get a default entry of 0, now causes an error. So before we can chastize
someone for not following a specification there has to actually be one.

Here are the results from 7.3:

t=> create table foo (bar int[]);
CREATE TABLE
t=> insert into foo values ('{1,,3}');
ERROR:  pg_atoi: zero-length string

t=> create table foo (bar text[]);
CREATE TABLE
t=> insert into foo values ('{"one",,"three"}');
INSERT 17047 1
t=> select * from foo;
      bar
----------------
 {one,"",three}
(1 row)

Cheers,
Steve

P.S. My vote for array behavior is to allow nulls within an array (as seems
from the docs to be the ultimate goal) and to continue to return a null from
any uninitialized array element. If selecting an element outside of an array
returns an error then it will be a pain to ask simple queries on variable
length arrays when you don't know in advance how many elements might exist in
each record. For example:
select count(*) from foo where bar[6] = 'snark';

-Steve

On Wednesday 18 December 2002 4:06 pm, Peter Eisentraut wrote:
> Bruce Momjian writes:
> > Folks, what do you want to do?
>
> Make them fix their code.
>
> It's one thing to have warts for allowing the market-leading GUI frontend
> for databases (MS Access) to work, but if every, with all due respect,
> random client wants to have its own break-the-spec-for-me switch we'll go
> mad.
>
> Explain to me why it's so hard to say 0 when you mean 0.