Upcoming events

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... Beta may start as soon as Saturday, September 1.

My guess is that end of *next* week would be more appropriate.

Personally I've finished all the major items I wanted to do for 7.2,
but there are still some little things that it'd be nice to clean up.
And we have a number of patches to review/apply. "Saturday" means
"now" as far as I'm concerned, since I won't be back from San Francisco
until Sunday ... it'd be nice to have a few more work days before beta.

Does anyone else have work that they're trying to finish up before
we go beta?

regards, tom lane

Does anyone else have work that they're trying to finish up before
we go beta?

Well, I did have a question that got lost in the details of the recent bytea
discussion. Specifically it was this: is there a good reason that byteaout
octal escapes all non-printable characters?

ISTM that if you are using bytea, it's because you need to store and
manipulate binary data, and therefore it ought to be the client's
responsibility to do any required escaping of the returned results. In the
work I'm doing with bytea presently, I either have to unescape it on the
client side, or use a binary cursor (and some app environments, like PHP,
don't currently give me the option of a binary cursor). Not that big of a
deal, but it doesn't seem right, and as you've seen by recent discussions it
confuses people.

The only reason I can think of for this behavior is that it makes the
results displayable in psql -- but again, I'd expect psql to deal with that,
not the backend.

Thoughts?

-- Joe

Do we want ADD PRIMARY KEY?

Chris

Does anyone else have work that they're trying to finish up before
we go beta?

Well, I did have a question that got lost in the details of the recent

bytea

discussion. Specifically it was this: is there a good reason that byteaout
octal escapes all non-printable characters?

ISTM that if you are using bytea, it's because you need to store and
manipulate binary data, and therefore it ought to be the client's
responsibility to do any required escaping of the returned results. In the
work I'm doing with bytea presently, I either have to unescape it on the
client side, or use a binary cursor (and some app environments, like PHP,
don't currently give me the option of a binary cursor). Not that big of a
deal, but it doesn't seem right, and as you've seen by recent discussions

it

confuses people.

The only reason I can think of for this behavior is that it makes the
results displayable in psql -- but again, I'd expect psql to deal with

that,

not the backend.

I guess add pg_dump to that list -- any others? Do you think there is a lot
of existing code?

-- Joe

"Joe Conway" <joseph.conway@home.com> writes:

... is there a good reason that byteaout
octal escapes all non-printable characters?

Well, AFAICS it *has to* escape nulls (zero bytes). Whether it escapes
more stuff is a matter of taste once you accept that.

What we really need to have to make bytea more useful is direct read and
write functions that don't require any escaping (a la large object
lo_read/lo_write).

regards, tom lane

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Do we want ADD PRIMARY KEY?

If you can get it done in the next week or so ...

regards, tom lane

Ya, lets go with the 10th of Sept, which is a Monday, start of the week
and all that, everyone has had a chance to relax once "the kids" are back
in school and all that :)

On Mon, 27 Aug 2001, Tom Lane wrote:

Aiiye. I'm sending a _large_ (60k) patch to add 'select * from cursor foo'
tonight. I'm hoping that it could possibly get included...

-alex

On Mon, 27 Aug 2001, Tom Lane wrote:

Ya, lets go with the 10th of Sept, which is a Monday, start of the week
and all that, everyone has had a chance to relax once "the kids" are back
in school and all that :)

Yes. I need to resolve all outstanding patches before we go beta and I
can use the extra time too. Can I suggest a pgindent run as soon as we
go beta? That way, we have maximum pgindent testing.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tom Lane wrote:

"Joe Conway" <joseph.conway@home.com> writes:

... is there a good reason that byteaout
octal escapes all non-printable characters?

Well, AFAICS it *has to* escape nulls (zero bytes). Whether it escapes
more stuff is a matter of taste once you accept that.

output function seems to escape all bytes <=\027 and >=\177

What we really need to have to make bytea more useful is direct read and
write functions that don't require any escaping (a la large object
lo_read/lo_write).

Two intertwined things we are currently missing:

1) a portable BINARY protocol (i _think_ that's what the typreceive and
typsend
fields in pg_type are meant to implement - currently they are allways
the same as
typinput, typoutput)

hannu=# select count(*) from pg_type where typreceive != typinput or
typsend != typoutput;
count
-------
0
(1 row)

2) a FE-BE protocol that allows first PREPARING a statement and then
EXECUTEing
it with args. Most DB's have it, SPI has it and both ODBC and JDBC have
it.
This should use the above-mentioned protocol to send the arguments to
execute.

having LO access to things is also nice, but it is independent of being
able to
easily store binary data in a database, especially if we claim PG to be
an ORDBMS.

-------------
Hannu

Does anyone else have work that they're trying to finish up before
we go beta?

I've got some (relatively small) patches to support some ISO variations
in date/time representation.

I'm considering diving in and separating timestamp into two types,
timestamp and timestamptz supporting "with and without" time zones as
has been discussed off and on for some time. I want to review the SQL99
spec a bit more (and get additional feedback on whether this is
desirable) before doing this though.

- Thomas

Does anyone else have work that they're trying to finish up before
we go beta?

I'm fixing and add some features to "to_char" (new to_char(interval) ).
Maybe I will finish it on this Friday.

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz