AsciiRow

Bruce Badger <bruce_badger@BadgerSE.com> writes:

The description of AsciiRow says that for each field it contains "the
value of the field itself in ASCII characters". The description is here:

http://postgresql.org/users-lounge/docs/7.3/postgres/protocol-message-formats.html

Looking at the bytes comming over the Frontend/Backend protocol,
however, it seems that the field is really always a String encoded
according to the settings in the database - is that right?

I believe this documentation's reference to ASCII shouldn't be taken
very literally; it really just means "text" (as opposed to some internal
binary representation) and is not meant to imply anything about one
character set encoding versus another. You're correct that the data
would actually appear in the currently-selected client encoding,
assuming that the backend is configured to support encoding conversions.

regards, tom lane

Hello everybody,

Some days ago was released pgaccess 0.98.8 This release marks the end
first phase of the work of the Redux team that came together in April
this year - Chris, Bartus, Brett, and some others.

After the release was renewed the practice weekly releases to be made.
They have the name pgaccess 0.98.8.20021216 - the last is the date of
the release, they mark the progress towards pgaccess 0.98.9

The anonymus CVS access still exists.

There are many new features, fixed bugs and improvements in pgaccess
0.98.8 in comparison to 0.98.7 - I will not use the space here, but all
interested can find them on the web site, and test it themselves.

What is may be most interesting is that several people start real small
applications based on pgaccess. Bartus does something for the company he
works for - that is pgaccess based. Chris has several small applications
in the pipeline (and also uses pgaccess for the company he works for).
There are one or two more names of people who are known to work actively
on using pgaccess as application building environment.

We hope that with this news we have made many of you happy. Those who
did not believe that anything good will come out of it - now have at
least a little bit proof.

Where are we heading from now? Improving pgaccess as an administrative
tool. And preparing the small foundations for making it an easier and
better applications building environment.

What we would like to see is a strong PostgreSQL. On UNIX, on Windows,
on Mac OS. On anything where Tcl/Tk works.

pgaccess has still open areas where people can work. Once on the very
core and the surrounding - documentation, tutorial. Second - broad and
endless - on small applications built using pgaccess. If anybody is
interesting - more information can be found on the web site.

With best Christmas wishes for everybody,

The pgaccess development team

www.pgaccess.org