atttypmod now 32 bits, interface change

Not that we have been sitting on our hands, but we have been waiting for the
FE/BE protocol to stabilize before updating the ODBC driver to the 6.4
specs. Have we reached this point?

Bruce Momjian wrote:

David Hartwig <daveh@insightdist.com> writes:

Not that we have been sitting on our hands, but we have been waiting for the
FE/BE protocol to stabilize before updating the ODBC driver to the 6.4
specs. Have we reached this point?

The cancel changeover and this atttypmod width business were the only
open issues I know about. I'm prepared to declare the protocol frozen
for 6.4 ... are there any objections?

regards, tom lane

Not that we have been sitting on our hands, but we have been waiting for the
FE/BE protocol to stabilize before updating the ODBC driver to the 6.4
specs. Have we reached this point?

Good point. I totally agree.

I think we have finally stabalized the protocol, with the CANCEL
completed last week by Tom Lane. As far as I know, the libpq and sgml
docs are updated, so you can use them to see the changes. If you need
details, I have kept some of Tom Lane's postings.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Not that we have been sitting on our hands, but we have been waiting for the
FE/BE protocol to stabilize before updating the ODBC driver to the 6.4
specs. Have we reached this point?

Of course, beta does not start until Sep 1, so it is possible to wait
some more to see of other things change before updating things, but
currently, there are no open items I know about.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

David Hartwig <daveh@insightdist.com> writes:

Not that we have been sitting on our hands, but we have been waiting for the
FE/BE protocol to stabilize before updating the ODBC driver to the 6.4
specs. Have we reached this point?

The cancel changeover and this atttypmod width business were the only
open issues I know about. I'm prepared to declare the protocol frozen
for 6.4 ... are there any objections?

I agree. We are done.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

The cancel changeover and this atttypmod width business were the only
open issues I know about. I'm prepared to declare the protocol frozen
for 6.4 ... are there any objections?

Sounds good. Should we ask Tatsuo to do some mixed-endian tests, or is
that area completely unchanged from v6.3?

- Tom

The cancel changeover and this atttypmod width business were the only
open issues I know about. I'm prepared to declare the protocol frozen
for 6.4 ... are there any objections?

Sounds good. Should we ask Tatsuo to do some mixed-endian tests, or is
that area completely unchanged from v6.3?

- Tom

Unchanged, I think.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Not that we have been sitting on our hands, but we have been waiting for the
FE/BE protocol to stabilize before updating the ODBC driver to the 6.4
specs. Have we reached this point?

Of course, beta does not start until Sep 1, so it is possible to wait
some more to see of other things change before updating things, but
currently, there are no open items I know about.

I have also renamed some of the client structure names used internally
by libpq. adtid, adtsize were too strange/confusing for me. Now they
are typid and typlen. Should help clarify why atttypmod is needed,
because many types, varchar(), don't have TYPE sizes.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

"Thomas G. Lockhart" <lockhart@alumnus.caltech.edu> writes:

Should we ask Tatsuo to do some mixed-endian tests, or is
that area completely unchanged from v6.3?

I don't think I broke anything in that regard ... but more testing is
always a good thing. If Tatsuo-san can spare the time, it would be
appreciated.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

"Thomas G. Lockhart" <lockhart@alumnus.caltech.edu> writes:

Should we ask Tatsuo to do some mixed-endian tests, or is
that area completely unchanged from v6.3?

I don't think I broke anything in that regard ... but more testing is
always a good thing. If Tatsuo-san can spare the time, it would be
appreciated.

Can't say as I really know that much about Japanese, but from what
I know about similar constructs in other languages, are you actually
asking if Tatsuo's son can do the tests? :)

-Brandon :)

At 11:32 AM 98.7.13 -0400, Tom Lane wrote:

"Thomas G. Lockhart" <lockhart@alumnus.caltech.edu> writes:

Should we ask Tatsuo to do some mixed-endian tests, or is
that area completely unchanged from v6.3?

I don't think I broke anything in that regard ... but more testing is
always a good thing. If Tatsuo-san can spare the time, it would be
appreciated.

Ok, I think I can start the testing next week.
This week I'm too busy because I have to finish writing an article
on PostgreSQL for a Japanese magazine!
By the way what are the visible changes of 6.4?
I know now we can cancel a query. Could you tell me any other
thing so that I could refer to them in the article?
--
Tatsuo Ishii
t-ishii@sra.co.jp

At 11:32 AM 98.7.13 -0400, Tom Lane wrote:

"Thomas G. Lockhart" <lockhart@alumnus.caltech.edu> writes:

Should we ask Tatsuo to do some mixed-endian tests, or is
that area completely unchanged from v6.3?

I don't think I broke anything in that regard ... but more testing is
always a good thing. If Tatsuo-san can spare the time, it would be
appreciated.

Ok, I think I can start the testing next week.
This week I'm too busy because I have to finish writing an article
on PostgreSQL for a Japanese magazine!
By the way what are the visible changes of 6.4?
I know now we can cancel a query. Could you tell me any other
thing so that I could refer to them in the article?

---------------------------------------------------------------------------

Nothing big that I can think of. Lots of cleanup/improvements to
existing areas. Vadim has some big items (as usual), but I don't think
we want to mention them publically yet.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

This week I'm too busy because I have to finish writing an article
on PostgreSQL for a Japanese magazine!
By the way what are the visible changes of 6.4?
I know now we can cancel a query. Could you tell me any other
thing so that I could refer to them in the article?

Nothing big that I can think of. Lots of cleanup/improvements to
existing areas.

Now Bruce! The automatic type coersion features are a pretty big change,
especially for the casual user; the columns in queries get matched up
and converted without any explicit work from the user. I can give Tatsuo
some examples if he would like. I'll bet there are a few other changes
which would give readers a good idea about the ongoing support and
improvements to Postgres...

Speaking of docs, we'll have SQL and utility commands in an
html/hardcopy reference manual. Hmm, may not be as exciting for Japanese
readers, but... :)

I've been updating the old release notes in the sgml sources, and have
that completed. Perhaps we can start the v6.4 release notes now? With
the sgml sources we can have more summary verbiage to help users get
introduced to new features, and then roll it out into a text file if
necessary.

- Tom

This week I'm too busy because I have to finish writing an article
on PostgreSQL for a Japanese magazine!
By the way what are the visible changes of 6.4?
I know now we can cancel a query. Could you tell me any other
thing so that I could refer to them in the article?

Nothing big that I can think of. Lots of cleanup/improvements to
existing areas.

Now Bruce! The automatic type coersion features are a pretty big change,
especially for the casual user; the columns in queries get matched up
and converted without any explicit work from the user. I can give Tatsuo
some examples if he would like. I'll bet there are a few other changes
which would give readers a good idea about the ongoing support and
improvements to Postgres...

Speaking of docs, we'll have SQL and utility commands in an
html/hardcopy reference manual. Hmm, may not be as exciting for Japanese
readers, but... :)

I've been updating the old release notes in the sgml sources, and have
that completed. Perhaps we can start the v6.4 release notes now? With
the sgml sources we can have more summary verbiage to help users get
introduced to new features, and then roll it out into a text file if
necessary.

I was afraid I was going to insult someone by saying what I did.

I MEANT that there are no features being added that a non-postgresql
user would be interested in. subselects was one feature that
non-postgresql users would understand. Most of our stuff now is
cleanup/extension of 6.3 features, many of which would be uninteresting
to potential users.

I suggest we focus on telling them about 6.3, which is ready NOW, and
has many nice features.

In fact, since we started two years ago, every release has gotten much
better than the previous, so we are now at a point where we are adding
'nifty' features like 'cancel' and atttypmod and stuff like that.

The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past. We are
nearing a maturity stage, where we can focus on performance,
documenation, features, and cleanup. The days when we have a 'major'
feature may be fewer, because we have added 'most' of the major features
people have been asking for.

Our user base is growing, and the number of sophisticated developers is
growing too, so we are getting major patches to improve lots of existing
functionality.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

At 18:37 +0300 on 14/7/98, Bruce Momjian wrote:

The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past. We are
nearing a maturity stage, where we can focus on performance,
documenation, features, and cleanup. The days when we have a 'major'
feature may be fewer, because we have added 'most' of the major features
people have been asking for.

Except row-level locking, referential integrity and PL/SQL...

Just an example of major features yet to be implemented (speaking from the
point of view of a user who doesn't know what the plans are for 6.4, of
course).

Herouth

(PS. This thread doesn't really have anything to do with the interfaces
list, does it? I redirected the crosspost to "general".)

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

At 18:37 +0300 on 14/7/98, Bruce Momjian wrote:

The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past. We are
nearing a maturity stage, where we can focus on performance,
documenation, features, and cleanup. The days when we have a 'major'
feature may be fewer, because we have added 'most' of the major features
people have been asking for.

Except row-level locking, referential integrity and PL/SQL...

I said the days would be fewer, not gone.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Bruce Momjian wrote:

I was afraid I was going to insult someone by saying what I did.

I MEANT that there are no features being added that a non-postgresql
user would be interested in. subselects was one feature that
non-postgresql users would understand. Most of our stuff now is
cleanup/extension of 6.3 features, many of which would be uninteresting
to potential users.

Not requiring the column to sort on in target list ia also quite
important.

As are the (still elementary) constraints, still elementary becuse
there is no way to use functions or "is null" in check constraint,
and constraints can be used only when defining tables, not in
"alter table" construct.

The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past.

Is anyone working on fixing the exploding optimisations for many OR-s,
at least the canonic case used by access?

My impression is that this has fallen somewhere between
insightdist and Vadim.

We are nearing a maturity stage, where we can focus on performance,
documenation, features, and cleanup. The days when we have a 'major'
feature may be fewer, because we have added 'most' of the major features
people have been asking for.

Expect them asking more soon ;)

I'm sure that soon being just basic ANSI SQL compliant is not enough;
people will want (in no particular order ;):
* ANSI CLI,
* updatable cursors,
* foreign key constraints,
* distributed databases,
* row level locking,
* better inheritance,
* domains,
* isolation levels,
* PL/SQL,
* better optimisation for special cases,
* temporary tables (both global and session level),
* more SQL3 constructs,
* unlisten command, maybe an argument to listen command,
* better support for installing your own access methods,
* separating the methods typinput/typoutput (native binary)
and typreceive/typsend (wire binary), they are in pg_type
* implementing a new fe/be protocol that is easier to implement
(does not mix zero terminated, and count-prefixed chunks),
preferrably modelled after X-Window protocol.
* getting rid of the 8k limitations, both in fe/be protocol and
in disk storage.

I know that some of these things are being worked on, but I've lost
track which are expected for 6.4, which for 6.5 and which I should
not expect before 8.0 ;)

Our user base is growing, and the number of sophisticated developers is
growing too, so we are getting major patches to improve lots of existing
functionality.

Yep. Great future is awaiting PostgreSQL.

I'm really looking forward to a time when I can find some time to
contribute some actual code.

Hannu

Bruce Momjian wrote:

I was afraid I was going to insult someone by saying what I did.

I MEANT that there are no features being added that a non-postgresql
user would be interested in. subselects was one feature that
non-postgresql users would understand. Most of our stuff now is
cleanup/extension of 6.3 features, many of which would be uninteresting
to potential users.

Not requiring the column to sort on in target list ia also quite
important.

As are the (still elementary) constraints, still elementary becuse
there is no way to use functions or "is null" in check constraint,
and constraints can be used only when defining tables, not in
"alter table" construct.

The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past.

Is anyone working on fixing the exploding optimisations for many OR-s,
at least the canonic case used by access?

My impression is that this has fallen somewhere between
insightdist and Vadim.

We are nearing a maturity stage, where we can focus on performance,
documenation, features, and cleanup. The days when we have a 'major'
feature may be fewer, because we have added 'most' of the major features
people have been asking for.

Expect them asking more soon ;)

I'm sure that soon being just basic ANSI SQL compliant is not enough;
people will want (in no particular order ;):
* ANSI CLI,
* updatable cursors,
* foreign key constraints,
* distributed databases,
* row level locking,
* better inheritance,
* domains,
* isolation levels,
* PL/SQL,
* better optimisation for special cases,
* temporary tables (both global and session level),
* more SQL3 constructs,
* unlisten command, maybe an argument to listen command,
* better support for installing your own access methods,
* separating the methods typinput/typoutput (native binary)
and typreceive/typsend (wire binary), they are in pg_type
* implementing a new fe/be protocol that is easier to implement
(does not mix zero terminated, and count-prefixed chunks),
preferrably modelled after X-Window protocol.
* getting rid of the 8k limitations, both in fe/be protocol and
in disk storage.

I know that some of these things are being worked on, but I've lost
track which are expected for 6.4, which for 6.5 and which I should
not expect before 8.0 ;)

Our user base is growing, and the number of sophisticated developers is
growing too, so we are getting major patches to improve lots of existing
functionality.

Yep. Great future is awaiting PostgreSQL.

I'm really looking forward to a time when I can find some time to
contribute some actual code.

Hannu

Hard to argue with this. There are more MAJOR things that I had
forgotten.

Still, I will say that the things we are working on now are more
'extras', than the stuff we were working on a year ago, which were
'usablility' issues.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Hannu Krosing wrote:

Not requiring the column to sort on in target list ia also quite
important.

I'm not sure but isn't this already in 6.4-current ?

As are the (still elementary) constraints, still elementary becuse
there is no way to use functions or "is null" in check constraint,

ispas=> create table t (x int, check (x is null or x = 5));
CREATE
ispas=> insert into t values (1);
ERROR: ExecAppend: rejected due to CHECK constraint $1
ispas=> insert into t values (null);
INSERT 168212 1
ispas=> insert into t values (5);
INSERT 168213 1

And I'm sure that functions are supported too. This is 6.3.2

and constraints can be used only when defining tables, not in
"alter table" construct.

I hadn't time to do this when implementing and have no plans
to do this. In "near" future :)

The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past.

Is anyone working on fixing the exploding optimisations for many OR-s,
at least the canonic case used by access?

My impression is that this has fallen somewhere between
insightdist and Vadim.

I'm not working...

Vadim