7.1.2 release

At 20:47 10/05/01 -0400, Bruce Momjian wrote:

Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.

I have not applied the latest pg_dump patches, and I'm still working on a
problem with the view extract.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

On Thu, 10 May 2001, Bruce Momjian wrote:

Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.

Not that I'm aware of ... I heard mention something about a couple of
fixes, but we *just* put out 7.1.1 ...

If ppl are affected by the bugs, use cvsup and set yoru tag to
REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ...

On Thu, 10 May 2001, Bruce Momjian wrote:

Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.

Not that I'm aware of ... I heard mention something about a couple of
fixes, but we *just* put out 7.1.1 ...

If ppl are affected by the bugs, use cvsup and set yoru tag to
REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ...

That is fine. I am not crazy about doing it now either. It is just
that Tom mentioned early in the week we need a release, and you said how
about Friday. I will brand 7.1.2 so it is ready whenever we want it.

-- 
  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

On Thu, 10 May 2001, Bruce Momjian wrote:

Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.

Not that I'm aware of ... I heard mention something about a couple of
fixes, but we *just* put out 7.1.1 ...

If ppl are affected by the bugs, use cvsup and set yoru tag to
REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ...

In fact, we can easily create a patch for this fix. It is only a few
lines.

-- 
  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

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

That is fine. I am not crazy about doing it now either. It is just
that Tom mentioned early in the week we need a release, and you said how
about Friday. I will brand 7.1.2 so it is ready whenever we want it.

I think I said Friday, not Marc ... and I didn't hear anyone else
agreeing with me anyway ;-)

We should certainly wait until Philip is happy with the state of
pg_dump. Right now I don't know of any other open issues.

regards, tom lane

Tom Lane wrote:

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

That is fine. I am not crazy about doing it now either. It is just
that Tom mentioned early in the week we need a release, and you said how
about Friday. I will brand 7.1.2 so it is ready whenever we want it.

I think I said Friday, not Marc ... and I didn't hear anyone else
agreeing with me anyway ;-)

Hmm I've thought no one has any objection :-).
I agree with you because the bug is very critical.

regards,
Hiroshi Inoue

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

I agree with you because the bug is very critical.

Yes, I'd like to get that plpgsql bug fix out as soon as possible.

But the pg_dump things that Philip is fixing are important too,
so I think we should wait a couple more days for those.
(Philip, we are just talking about a few days, right?)

regards, tom lane

On Thu, 10 May 2001, Tom Lane wrote:

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

I agree with you because the bug is very critical.

Yes, I'd like to get that plpgsql bug fix out as soon as possible.

Isn't this only critical for those that are using it? Does it affect
those that don't use plpgsql?

While you guys are still awake, I may as well ask this:

I gather that the following code goes though the heap and removes all check
contraints associated with a particular table, but how do I extend the code
to match both a table relid and the constraint name? Basically I'm just
asking how I express 'SQL SELECT' queries using the heap access functions?

rcrel = heap_openr(RelCheckRelationName, RowExclusiveLock);
ScanKeyEntryInitialize(&key, 0, Anum_pg_relcheck_rcrelid,
F_OIDEQ, RelationGetRelid(rel));

rcscan = heap_beginscan(rcrel, 0, SnapshotNow, 1, &key);

while (HeapTupleIsValid(tup = heap_getnext(rcscan, 0)))
simple_heap_delete(rcrel, &tup->t_self);

heap_endscan(rcscan);
heap_close(rcrel, RowExclusiveLock);

Cheers,

Chris

The Hermit Hacker <scrappy@hub.org> writes:

Isn't this only critical for those that are using it? Does it affect
those that don't use plpgsql?

No, but I think it's pretty critical for those that do ...

regards, tom lane

At 22:43 10/05/01 -0400, Tom Lane wrote:

(Philip, we are just talking about a few days, right?)

Yes - it's waiting on the problem Zoltan reported (the select from
pg_rewrite etc). I can't reproduce the problem on any of my DBs.

If worst comes to worst, I have a (nasty) workaround, but I'm more worried
that it might reflect a larger problem with the way I have used
column-select expressions in pg_dump.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

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

I gather that the following code goes though the heap and removes all check
contraints associated with a particular table, but how do I extend the code
to match both a table relid and the constraint name?

Add another ScanKey. Look at uses of ScanKeyEntryInitialize for examples.

regards, tom lane

Philip Warner <pjw@rhyme.com.au> writes:

Yes - it's waiting on the problem Zoltan reported (the select from
pg_rewrite etc). I can't reproduce the problem on any of my DBs.

I've just realized that the problem is a lot simpler than it appears.
The given string is too long for a NAME:

regression=# select ('_RET' || 'szallitolevel_tetele_ervenyes')::name;
?column?
---------------------------------
_RETszallitolevel_tetele_erveny
(1 row)

When you write

select oid from pg_rewrite where
rulename='_RETszallitolevel_tetele_ervenyes'

the unknown-type literal is coerced to NAME --- ie truncated --- and
then the comparison works. But when you write

select oid from pg_rewrite where
rulename='_RET' || 'szallitolevel_tetele_ervenyes'

the result of the || will be type TEXT not type NAME. So the rulename
gets promoted to TEXT and texteq is used ... with the result that
_RETszallitolevel_tetele_ervenye does not match
_RETszallitolevel_tetele_ervenyes.

Solution: don't use ||, or explicitly cast its result to NAME:

select oid from pg_rewrite where
rulename=('_RET' || 'szallitolevel_tetele_ervenyes')::name

regards, tom lane

At 01:28 11/05/01 -0400, Tom Lane wrote:

Philip Warner <pjw@rhyme.com.au> writes:

Yes - it's waiting on the problem Zoltan reported (the select from
pg_rewrite etc). I can't reproduce the problem on any of my DBs.

I've just realized that the problem is a lot simpler than it appears.
The given string is too long for a NAME:

Ung. That's a bit nasty for views:

pjw=# create view szallitolevel_tetele_erveny01 as select * from t1;
CREATE
pjw=# create view szallitolevel_tetele_erveny02 as select * from t1;
ERROR: Attempt to insert rule "_RETszallitolevel_tetele_erveny" failed:
already exists

But at least I can fix pg_dump now.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

On Thu, 10 May 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

Isn't this only critical for those that are using it? Does it affect
those that don't use plpgsql?

No, but I think it's pretty critical for those that do ...

So, why not create a quick patch for those that need it, and let those
with the capability pull from CVS/CVSup ... that is why we have them setup
...

Bruce Momjian writes:

Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.

Make sure you are labelling the documentation with the correct version.
Thomas should set up his documentation build area for the current and
stable branches, and Marc has to make sure that the mk-release picks up
the right one. Right now it would probably pick up current, which is
definitely not right. Man, this should be easier.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Philip Warner <pjw@rhyme.com.au> writes:

I have not applied the latest pg_dump patches, and I'm still working on a
problem with the view extract.

Philip, I see you applied some pg_dump patches yesterday. Have you
resolved all your outstanding issues, or is there still more you want
to do before 7.1.2?

regards, tom lane

Bruce Momjian writes:

Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.

Make sure you are labelling the documentation with the correct version.
Thomas should set up his documentation build area for the current and
stable branches, and Marc has to make sure that the mk-release picks up
the right one. Right now it would probably pick up current, which is
definitely not right. Man, this should be easier.

I have stamped the SGML version file for each release appropriately.

-- 
  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

At 13:47 12/05/01 -0400, Tom Lane wrote:

Philip, I see you applied some pg_dump patches yesterday. Have you
resolved all your outstanding issues, or is there still more you want
to do before 7.1.2?

Everything I know about is resolved.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

Philip Warner <pjw@rhyme.com.au> writes:

Philip, I see you applied some pg_dump patches yesterday. Have you
resolved all your outstanding issues, or is there still more you want
to do before 7.1.2?

Everything I know about is resolved.

Okay, good. I did some experimentation this afternoon with dumping the
7.0 regression database using both native 7.0 pg_dump and the
current-sources one. Seemed to work pretty well, though I did make one
change: I think we should assume proisstrict = FALSE when dumping from a
7.0 db, not TRUE. The forcing consideration for this is that I was
getting "isstrict" markers on plpgsql_call_handler, which would be a
really nasty problem if it got into the field: people would report that
they couldn't get plpgsql functions to work with NULLs, and we'd be
unable to duplicate the misbehavior. More generally, it doesn't matter
for old C functions, because the fmgr_oldstyle wrapper will cause the
right things to happen, and I don't think we want to force strictness
for SQL or PL functions. (That's why I chose CREATE FUNCTION's default
to be non strict...)

regards, tom lane