[Info-vax] Status of the PostgreSQL port?

[Stephen Hoffman]

On 2015-06-30 01:27:35 +0000, John Reagan said:


Start acting like VSI can and does lead this whole show, that VSI has a 
vision, that VSI can and does know how programs should be written, and 
how applications should work.

Provide warnings and an explanation and a schedule and a migration path 
for existing code, and break the APIs that need to be broken.  Do not 
be arbitrary about this, and do not break APIs that do not need to be 
broken.  But do not fear breaking compatibility where you have a good 
reason to do so, and make sure you can explain why and what to do.   
Spend less time keeping the folks with the most utterly awful code 
happy at the expense of the folks that are actually updating their code 
and creating new applications and using the newer features.   Folks 
that aren't updating their code and that aren't fixing bugs and aren't 
using the new features aren't your future, and they can be well served 
by an LTS release, if you want their money and have the staff available.

> From VAX to Alpha, we did a pretty good job at recompile-and-go.  That 
> was near the VAX C to DEC C transition which had nothing to do with 
> Alpha directly.
> 
> OK, who wants to get rid of /STANDARD=VAXC?

Announce the deprecation and the schedule last week or last year, and 
then nuke VAX C from orbit.  Maybe combined as part of some 
announcement of C11 support.

Nuking VAX C will help with more than a few support issues arising from 
bad code and suppressed diagnostics, too.

> #pragma warning ?

Unrecognized pragmas get diagnostics, or get ignored.

> VAX floating support?

Deprecate VAX floating point support, outside of providing the CVT$ 
calls or analogous calls.   For the folks that need it, they can 
convert the data or call the conversion routines.

> Mixed-pointer sizes?

Announce that an unspecified future release of an unspecified operating 
system will be using a 64-bit flat address space.   Let old 32-bit apps 
run where and if and when that's reasonably feasible, but otherwise 
give a very solid shove to get everybody onto a flat 64-bit address 
space, either native or sign-extended.   No mixed pointers.   Get rid 
of the segmented address space design.   Provide the new calls and the 
new features and the rest of the enhancements only in 64-bit land, 
where that's feasible.



There are other areas...

Announce that the disk sector sizes will be changing, and folks should 
start using DVI$_DEVBUFSIZ at run-time, or (maybe!) a constant and 
always assume block sizes of 16384 or some such.

Announce the deprecation the non-length-enforced C string calls, akin 
to what has happened with Microsoft Windows and OpenBSD.

Make the IOSB a required argument.

Provide (explicit opt-in) integrated application dump features and 
uploads, and integrated system and application software update and 
distribution and notification mechanisms, and (again, opt-in) 
automatically collect all crashdumps including systems and applications.

Etc.



In short, determine what a modern OpenVMS operating system looks like, 
explain your vision, explain how we're going to get there and how it'll 
simplify the application code and the maintenance and updates and the 
rest, and start moving everybody toward it.




-- 
Pure Personal Opinion | HoffmanLabs LLC