Thread: Upcoming events
Here are a few dates of interest: Monday-Friday: Tom, Jan, and I will be at LinuxWorld in San Francisco. Vadim will be at LinuxWorld too, but of course he lives in San Francisco. Beta may start as soon as Saturday, September 1. I know Tom has mentioned it and no one has said anything contrary. This of course could change. I will be on vacation in Lebanon/Syria from September 16 to October 17. I will be on-line 1-2 days a week from that location, so I will be around, but not as frequently available. OSDN Database Summit is September 23-25 in Providence, Rhode Island. Though I was supposed to attend, I will now not be able to. Tom Lane will give my presentation. It was a very enjoyable event when I attended last year. -- 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, Pennsylvania19026
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 > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane > Sent: Tuesday, 28 August 2001 8:56 AM > To: Bruce Momjian > Cc: PostgreSQL-development > Subject: Re: [HACKERS] 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
"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
> > 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
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: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
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: > "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 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
> > 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, Pennsylvania19026
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