beta time

Bruce Momjian wrote:

I have two things left before beta. I want to make sure the release
notes are current against CVS and I want to make sure the win32
tablespace symlink changes I just made work.

Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

I have two things left before beta. I want to make sure the release
notes are current against CVS and I want to make sure the win32
tablespace symlink changes I just made work.

Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?

Yes I did. I think the release notes are good to go for beta,
with the possible exception of mentioning any array-input-parsing
hacking that Joe might be about to commit.

I think though that we might have some other must-fix Win32 issues :-(.
What are we going to do about this libpgport-depends-on-the-backend
business?

regards, tom lane

Tom Lane wrote:

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

Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?

Yes I did. I think the release notes are good to go for beta,
with the possible exception of mentioning any array-input-parsing
hacking that Joe might be about to commit.

I was waiting on feedback on two issues before committing:

1. '{{"1 2" x},{3}}'
2. '{{},{}}'

My patch would generate an ERROR for either. Tom, you questioned my
disallowing of both of these, but didn't seem to have a very strong
opinion. No one else has chimed in at all (including no replies to my
post on GENERAL earlier). Can I go with what I have, at the risk of
ripping it out if others complain?

If so, I'll commit what I posted last night, and amend the docs. I will
also update the release notes.

BTW, when is the planned cutoff for commits to get into the beta?

Thanks,

Joe

Tom Lane wrote:

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

I have two things left before beta. I want to make sure the release
notes are current against CVS and I want to make sure the win32
tablespace symlink changes I just made work.

Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?

Yes I did. I think the release notes are good to go for beta,
with the possible exception of mentioning any array-input-parsing
hacking that Joe might be about to commit.

OK. Thanks for doing that.

I think though that we might have some other must-fix Win32 issues :-(.
What are we going to do about this libpgport-depends-on-the-backend
business?

I have Claudio on IM right now and am getting the details. I wasn't
aware it was such a problem but I think it was introduced by rmtree()
and the malloc call.

What I would like to do is to move elog/fprintf out of /port and make a
generic pglog call and have a backend function that calls elog and a
libpq version that calls fprintf. This would remove a lot of FRONTEND
and Makefile compiles and will probably avoid some bugs. The only
tricky part is passing a variable number of arguments. Same behavior for
malloc/palloc.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Joe Conway wrote:

Tom Lane wrote:

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

Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?

Yes I did. I think the release notes are good to go for beta,
with the possible exception of mentioning any array-input-parsing
hacking that Joe might be about to commit.

I was waiting on feedback on two issues before committing:

1. '{{"1 2" x},{3}}'
2. '{{},{}}'

My patch would generate an ERROR for either. Tom, you questioned my
disallowing of both of these, but didn't seem to have a very strong
opinion. No one else has chimed in at all (including no replies to my
post on GENERAL earlier). Can I go with what I have, at the risk of
ripping it out if others complain?

If so, I'll commit what I posted last night, and amend the docs. I will
also update the release notes.

OK, it has to go in the incompatibilities section, right?

BTW, when is the planned cutoff for commits to get into the beta?

When everyone is done sometime tomorrow.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Joe Conway <mail@joeconway.com> writes:

I was waiting on feedback on two issues before committing:

1. '{{"1 2" x},{3}}'
2. '{{},{}}'

My patch would generate an ERROR for either. Tom, you questioned my
disallowing of both of these, but didn't seem to have a very strong
opinion.

I don't have any great love for the first item --- I think it was an
unintended consequence of the way the code was first written, rather
than something the author meant to support.

I'm more concerned about what the second should mean, but I do have to
concede that we'd likely want to appropriate this syntax to mean NULL
array entries as soon as we support NULL array entries. So rejecting it
at the moment may be a forward-looking thing to do.

BTW, when is the planned cutoff for commits to get into the beta?

The plan was to wrap beta1 sometime tomorrow ... I'd guess that
"sometime" will end up being in the afternoon east coast time, but
this largely depends on the libpgport breakage ...

regards, tom lane

On Sat, 7 Aug 2004, Tom Lane wrote:

The plan was to wrap beta1 sometime tomorrow ... I'd guess that
"sometime" will end up being in the afternoon east coast time, but this
largely depends on the libpgport breakage ...

That's what I was figuring (re: libpgport) ... hopefully I'm following the
right one, but am following the thread, and will hold off pending
resolution ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

1. '{{"1 2" x},{3}}'
2. '{{},{}}'

My patch would generate an ERROR for either. Tom, you questioned my
disallowing of both of these, but didn't seem to have a very strong
opinion.

I don't have any great love for the first item --- I think it was an
unintended consequence of the way the code was first written, rather
than something the author meant to support.

I'm more concerned about what the second should mean, but I do have to
concede that we'd likely want to appropriate this syntax to mean NULL
array entries as soon as we support NULL array entries. So rejecting it
at the moment may be a forward-looking thing to do.

I committed the attached.

Regarding the release notes, I take it that we should modify
doc/src/sgml/release.sgml? Does the following sound reasonable, or
should I provide specific examples?

<listitem>
<para>
Syntax checking of array input processing has been tighened up
considerably. Junk that was previously allowed in odd places with
odd results now causes an ERROR. Also changed behavior with respect
to whitespace; trailing whitespace is now ignored as well as leading
whitespace (which has always been ignored).
</para>
</listitem>

Joe

Joe Conway wrote:

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

1. '{{"1 2" x},{3}}'
2. '{{},{}}'

My patch would generate an ERROR for either. Tom, you questioned my
disallowing of both of these, but didn't seem to have a very strong
opinion.

I don't have any great love for the first item --- I think it was an
unintended consequence of the way the code was first written, rather
than something the author meant to support.

I'm more concerned about what the second should mean, but I do have to
concede that we'd likely want to appropriate this syntax to mean NULL
array entries as soon as we support NULL array entries. So rejecting it
at the moment may be a forward-looking thing to do.

I committed the attached.

Regarding the release notes, I take it that we should modify
doc/src/sgml/release.sgml? Does the following sound reasonable, or

Right.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Joe Conway <mail@joeconway.com> writes:

I committed the attached.

Minor gripe: this bit of documentation seems out of date now.

! For example, elements containing curly braces, commas (or whatever the
! delimiter character is), double quotes, backslashes, or leading white
! space must be double-quoted. To put a double quote or backslash in a

Should say "leading or trailing whitespace", no?

Regarding the release notes, I take it that we should modify
doc/src/sgml/release.sgml?

Yup.

Does the following sound reasonable, or
should I provide specific examples?

Seems roughly the right amount of detail to me. Note you should make
entries under both "observe the following incompatibilities" and the
general list of datatype/function changes.

regards, tom lane

On Sat, Aug 07, 2004 at 10:09:22PM -0700, Joe Conway wrote:

<listitem>
<para>
Syntax checking of array input processing has been tighened up
considerably. Junk that was previously allowed in odd places with
odd results now causes an ERROR. Also changed behavior with respect
to whitespace; trailing whitespace is now ignored as well as leading
whitespace (which has always been ignored).
</para>
</listitem>

Whitespace where?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No hay ausente sin culpa ni presente sin disculpa" (Prov. franc�s)

Tom Lane wrote:

Minor gripe: this bit of documentation seems out of date now.

! For example, elements containing curly braces, commas (or whatever the
! delimiter character is), double quotes, backslashes, or leading white
! space must be double-quoted. To put a double quote or backslash in a

Should say "leading or trailing whitespace", no?

Good catch. Fixed.

Seems roughly the right amount of detail to me. Note you should make
entries under both "observe the following incompatibilities" and the
general list of datatype/function changes.

Yup, figured that out after I sent the last post. Done.

Thanks,

Joe

Alvaro Herrera wrote:

Whitespace where?

OK, clarified:

<para>
Syntax checking of array input processing has been tighened up
considerably. Junk that was previously allowed in odd places with
odd results now causes an ERROR. Also changed behavior with respect
to whitespace surrounding array elements; trailing whitespace is now
ignored as well as leading whitespace (which has always been ignored).
</para>

Thanks,

Joe

OK, I fixed the Win32 pgport build problem with Claudio's help.

I also fixed pg_dumpall on Win32 at the same time.

I might be out most of the day tomorrow.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073