On Mon, Jan 13, 2014 at 3:45 PM, David Fetter <da...@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
