Disallow arrays with non-standard lower bounds
ISTM that allowing users to pick arbitrary lower array bounds was a huge mistake. I've never seen anyone make use of it, can't think of any legitimate use cases for it, and hate the stupendous amount of extra code needed to deal with it.
Obviously we can't just drop support, but what about an initdb (or hell, even configure) option to disallow arrays with a lower bound <> 1? Unfortunately we can't do this with a GUC since you can store arrays in a table.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 9, 2014 at 2:30 PM, Jim Nasby <jim@nasby.net> wrote:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make use of it, can't think of any
legitimate use cases for it, and hate the stupendous amount of extra code
needed to deal with it.
I agree with this, but I think it's too late. I don't think the answer
is any type of parameter.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 09, 2014 at 04:30:25PM -0600, Jim Nasby wrote:
ISTM that allowing users to pick arbitrary lower array bounds was a
huge mistake. I've never seen anyone make use of it, can't think of
any legitimate use cases for it, and hate the stupendous amount of
extra code needed to deal with it.Obviously we can't just drop support, but what about an initdb (or
hell, even configure) option to disallow arrays with a lower bound
<> 1? Unfortunately we can't do this with a GUC since you can store
arrays in a table.
We have dropped support, as you put it, for bigger and harder-hitting
mistakes than this. Anybody whose code has this kind of silliness in
it will be in other kinds of trouble, too.
Cheers,
David (who is among that tiny minority who believe that arrays should
be indexed from 0.5 as a compromise ;)
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/01/14 12:41, David Fetter wrote:
[..]
David (who is among that tiny minority who believe that arrays should
be indexed from 0.5 as a compromise ;)
Clearly we should use 1/e as the starting index, where 'e' is Euler's
constant 2.718... :-)
(Much more mathematically profound!)
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 9, 2014 at 3:41 PM, David Fetter <david@fetter.org> wrote:
We have dropped support, as you put it, for bigger and harder-hitting
mistakes than this. Anybody whose code has this kind of silliness in
it will be in other kinds of trouble, too.
While the decision to make it possible to set the lower bound index
value arbitrarily was made before I was active in the project, I
imagine it went something like this:
Person 1: We should make our arrays similar to those found in a
certain proprietary system's standard procedural language - with one
as a lower bound.
Person 2: I don't like that, it should always be zero.
Person 1: We can all be winners.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/01/14 12:55, Peter Geoghegan wrote:
On Thu, Jan 9, 2014 at 3:41 PM, David Fetter <david@fetter.org> wrote:
We have dropped support, as you put it, for bigger and harder-hitting
mistakes than this. Anybody whose code has this kind of silliness in
it will be in other kinds of trouble, too.While the decision to make it possible to set the lower bound index
value arbitrarily was made before I was active in the project, I
imagine it went something like this:Person 1: We should make our arrays similar to those found in a
certain proprietary system's standard procedural language - with one
as a lower bound.Person 2: I don't like that, it should always be zero.
Person 1: We can all be winners.
Starting arrays at zero makes the most sense, as then you can calculate
the displacement simply as (index) * (size of entry), and not have
subtract one from the index first. This would be my preference.
Both C & C++ use zero as the default, so Java naturally followed their
example.
But I wouldn't push it, as people who mainly know SQL are more used to
starting arrays at 1, and it is not worth the effort to change it as
this stage. At least we should be consistent how we treat arrays in SQL.
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge mistake. I've never seen anyone make use of it, can't think of any legitimate use cases for it, and hate the stupendous amount of extra code needed to deal with it.
You lack imagination, sir.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge mistake. I've never seen anyone make use of it, can't think of any legitimate use cases for it, and hate the stupendous amount of extra code needed to deal with it.
You lack imagination, sir.
Considering what you'd normally want to do in SQL, the only example I can think of is to not have the argument over 0 vs 1 based.
Actually, I was thinking there might be some computational problems where changing lower bound would be nice, but then again, what other languages actually support this?
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/10/2014 04:26 PM, Jim Nasby wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was a
huge mistake. I've never seen anyone make use of it, can't think of
any legitimate use cases for it, and hate the stupendous amount of
extra code needed to deal with it.You lack imagination, sir.
Considering what you'd normally want to do in SQL, the only example I
can think of is to not have the argument over 0 vs 1 based.Actually, I was thinking there might be some computational problems
where changing lower bound would be nice, but then again, what other
languages actually support this?
Ada, for one. In fact, in Ada the index doesn't need to be an integer,
just an enumerable type (e.g. an enum). You can iterate over
one-dimensional arrays by saying:
FOR i IN [REVERSE] my_array'range LOOP ...
cheers
andrew (who sadly hasn't used Ada in anger for about 20 years).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 10, 2014 at 03:26:04PM -0600, Jim Nasby wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was
a huge mistake. I've never seen anyone make use of it, can't think
of any legitimate use cases for it, and hate the stupendous amount
of extra code needed to deal with it.You lack imagination, sir.
Considering what you'd normally want to do in SQL, the only example
I can think of is to not have the argument over 0 vs 1 based.Actually, I was thinking there might be some computational problems
where changing lower bound would be nice, but then again, what other
languages actually support this?
Well, there's Perl, but that's not an argument *for* doing this, and I
say that as a long-time Perl user (who has never seen this feature
used in code worth not scrapping, by the way).
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
Starting arrays at zero makes the most sense, as then you can
calculate the displacement simply as (index) * (size of entry),
and not have subtract one from the index first. This would be my
preference.
The SQL standard explicitly specifies that arrays positions range
from 1 to the cardinality of the array, with individual elements
referenced by position. When implementing a language for which
there is an international standard, my preference is to conform to
the standard.
I don't have a problem with extensions to the language, and a
variable low bound is workable as an extension as long as the
standard ways to create an array default to a low bound of 1.
A bigger problem with our array implementation is that is is really
a multidimensional matrix, rather than an array which can contain
nested arrays. That is both non-standard and limiting.
That said, I think it would be nice to have better support for
arrays defined with a single dimension and a low bound of 1, as the
standard requires. Functions which throw an error when passed a
non-conforming parameter and can provide a simplified API as a
result would probably get used by me.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby <jim@nasby.net> wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make use of it, can't think of any
legitimate use cases for it, and hate the stupendous amount of extra code
needed to deal with it.You lack imagination, sir.
Considering what you'd normally want to do in SQL, the only example I can
think of is to not have the argument over 0 vs 1 based.Actually, I was thinking there might be some computational problems where
changing lower bound would be nice, but then again, what other languages
actually support this?
Perl does, though they regret it bitterly.
Cheers,
Jeff
On Fri, Jan 10, 2014 at 4:10 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby <jim@nasby.net> wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make use of it, can't think of any
legitimate use cases for it, and hate the stupendous amount of extra code
needed to deal with it.You lack imagination, sir.
Considering what you'd normally want to do in SQL, the only example I can
think of is to not have the argument over 0 vs 1 based.Actually, I was thinking there might be some computational problems where
changing lower bound would be nice, but then again, what other languages
actually support this?Perl does, though they regret it bitterly.
What does it matter? Our arrays have had the capability for years and
years and "because it's cleaner" is simply not justification to break
people's applications. Why are we even considering this?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/10/14, 4:14 PM, Merlin Moncure wrote:
On Fri, Jan 10, 2014 at 4:10 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby <jim@nasby.net> wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby <jim@nasby.net> writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make use of it, can't think of any
legitimate use cases for it, and hate the stupendous amount of extra code
needed to deal with it.You lack imagination, sir.
Considering what you'd normally want to do in SQL, the only example I can
think of is to not have the argument over 0 vs 1 based.Actually, I was thinking there might be some computational problems where
changing lower bound would be nice, but then again, what other languages
actually support this?Perl does, though they regret it bitterly.
What does it matter? Our arrays have had the capability for years and
years and "because it's cleaner" is simply not justification to break
people's applications. Why are we even considering this?
Because it's a foot-gun. So far no one has given a legitimate use case for it and supporting it *greatly* complicates iterating over arrays.
Also, just to be clear, I'd be fine with offering a better alternative and leaving existing arrays alone. I don't see any easy way to do that, but maybe someone's got a good idea on that.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/10/2014 07:41 AM, David Fetter wrote:
On Thu, Jan 09, 2014 at 04:30:25PM -0600, Jim Nasby wrote:
ISTM that allowing users to pick arbitrary lower array bounds was a
huge mistake. I've never seen anyone make use of it, can't think of
any legitimate use cases for it, and hate the stupendous amount of
extra code needed to deal with it.Obviously we can't just drop support, but what about an initdb (or
hell, even configure) option to disallow arrays with a lower bound
<> 1? Unfortunately we can't do this with a GUC since you can store
arrays in a table.We have dropped support, as you put it, for bigger and harder-hitting
mistakes than this.
Implicit casts to text, anybody?
Everybody used them. The project dropped them anyway, and did so pretty
much unconditionally at that.
This is a vastly less heavily used feature. I'd be really, really glad
to see it disabled by default at initdb time, with a warning saying the
initdb option to enable it will go away in a few versions.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
Implicit casts to text, anybody?
This backward compatibility break orphaned the company I work for on
8.1 until last year and very nearly caused postgres to be summarily
extirpated (only rescued at the last minute by my arrival). It cost
hundreds of thousands of dollars to qualify a sprawling java code base
so that it could be moved back into a supported version. Breaking
compatibility sucks -- it hurts your users and costs people money.
Hacking type casts may not have been a mistake, but the arbitrary
introduction of the breakage certainly was.
This project has no deprecation policy, and I'd argue we'd need one
before considering breaking changes. For example, maybe we could pull
out an occasional release for longer term support to help users that
caught out. But really, the better way to go IMNSHO is to take a
hard line on compatibility issues pretty much always -- consider the
case of libc and win32 api. There are certain limited exceptions to
this rule -- for example security problems or gross violations of the
standard (bringing row-wise comparison to spec comes to mind as an
example of that).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/13/14, 10:40 AM, Merlin Moncure wrote:
On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer<craig@2ndquadrant.com> wrote:
Implicit casts to text, anybody?
This backward compatibility break orphaned the company I work for on
8.1 until last year and very nearly caused postgres to be summarily
extirpated (only rescued at the last minute by my arrival). It cost
hundreds of thousands of dollars to qualify a sprawling java code base
so that it could be moved back into a supported version. Breaking
compatibility sucks -- it hurts your users and costs people money.
Hacking type casts may not have been a mistake, but the arbitrary
introduction of the breakage certainly was.
IMHO, I see no reason we need to plan on removing support. Presumably it's not that much burden on our codebase; it's only a PITA for users writing correct code. (It'd be very interesting to see how much user code would blow up if presented with anything other than 1 as the lower bound...)
I'd be perfectly happy with an initdb option to allow for lower bound support if you wanted it and disable it by default. People the legitimately want/need <> 1 lower bounds can set that up, but our general user population will end up protected from a class of heisenbugs.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 13, 2014 at 10:40:57AM -0600, Merlin Moncure wrote:
On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
Implicit casts to text, anybody?
This backward compatibility break orphaned the company I work for on
8.1 until last year and very nearly caused postgres to be summarily
extirpated (only rescued at the last minute by my arrival). It cost
hundreds of thousands of dollars to qualify a sprawling java code base
so that it could be moved back into a supported version. Breaking
compatibility sucks -- it hurts your users and costs people money.
Hacking type casts may not have been a mistake, but the arbitrary
introduction of the breakage certainly was.
With utmost respect, it was not. Databases are no good if there are
fixable things in them that cause them to produce incorrect results at
random, as auto-casting to text did.
This project has no deprecation policy,
I believe it actually does, although it's not a formal, written
policy. Would you like to help draft one up?
and I'd argue we'd need one
before considering breaking changes. For example, maybe we could pull
out an occasional release for longer term support to help users that
caught out. But really, the better way to go IMNSHO is to take a
hard line on compatibility issues pretty much always -- consider the
case of libc and win32 api.
Could you please help remind us what that was?
There are certain limited exceptions to this rule -- for example
security problems
Probably not.
or gross violations of the standard
We're definitely there on lower bounds of arrays. The standard, for a
wonder, is clear and unambiguous about them. Whether we should go
there on the rest of our array implementation is a question for
another thread.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 13, 2014 at 4:45 PM, David Fetter <david@fetter.org> wrote:
On Mon, Jan 13, 2014 at 10:40:57AM -0600, Merlin Moncure wrote:
On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
Implicit casts to text, anybody?
This backward compatibility break orphaned the company I work for on
8.1 until last year and very nearly caused postgres to be summarily
extirpated (only rescued at the last minute by my arrival). It cost
hundreds of thousands of dollars to qualify a sprawling java code base
so that it could be moved back into a supported version. Breaking
compatibility sucks -- it hurts your users and costs people money.
Hacking type casts may not have been a mistake, but the arbitrary
introduction of the breakage certainly was.With utmost respect, it was not. Databases are no good if there are
fixable things in them that cause them to produce incorrect results at
random, as auto-casting to text did.
With a precisely equal level of respect, that's a load of bunk. As
has been discussed here many times in the past, those changes broke
many applications that were just fine. Mine included, EnterpriseDB's
included. It was designed to maximize rather than minimize breakage
in ways that were completely unnecessary, and every time anyone dares
to argue that the change was less than perfect in every respect, the
reponses evince a level of dubiousness normally reserved for the
parole hearings of convicted murderers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 13, 2014 at 3:45 PM, David Fetter <david@fetter.org> wrote:
On Mon, Jan 13, 2014 at 10:40:57AM -0600, Merlin Moncure wrote:
This project has no deprecation policy,
I believe it actually does, although it's not a formal, written
policy. Would you like to help draft one up?
Lack of 'formal, written, policy' is equivalent to 'no policy'.
Regardless, the way things we done in the 7.x/8.x series may no longer
apply today; the project has grown up and we need to be more serious
about things, at least, IMNSHO.
and I'd argue we'd need one
before considering breaking changes. For example, maybe we could pull
out an occasional release for longer term support to help users that
caught out. But really, the better way to go IMNSHO is to take a
hard line on compatibility issues pretty much always -- consider the
case of libc and win32 api.Could you please help remind us what that was?
Let's take gets() for example. C11 finally ditched it 12 years (!)
after it was formally deprecated in C99 and informally deprecate in
endless man pages ("don't use this!") for decades before that. And
even then most compilers, at least the decent ones, should allow to
request previous standards for some time beyond that. The win32 API
is also remarkably stable; ancient code written for it beyond the dim
horizon of time will still compile and execute today. These are
probably strong contenders for most popular APIs ever made -- see the
connection? Now, comparing C APIs to an SQL implementation for
deprecation purposes isn't quite applies to apples, but I'll stand by
the analogy.
or gross violations of the standard
We're definitely there on lower bounds of arrays. The standard, for a
wonder, is clear and unambiguous about them. Whether we should go
there on the rest of our array implementation is a question for
another thread.
The SQL standard requests that standard syntax gives standard
behavior. Alternate bounds is non-standard syntax giving non-standard
behavior and is thus excepted. Naturally, non-standard syntax is
dangerous because the standard may later implement it in which case
you then have a real problem (that may be the case here: I don't
know). Our array implementation is a real mess on multiple levels but
at least it's an internally consistent mess. Maybe it really should
be 'fixed', but not before the super un-fun discussion of how to ease
the path for our hapless users happens first.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
