Open 7.3 issues

Dependency - have pg_dump auto-create dependencies when loading 7.2.X
data?

Are we as far as we can go here?

The only trouble maker is foreign keys. If there was a nice way of
finding foreign keys in 7.2 and prior it probably would have been
implemented a long time ago in pg_dump :)

Something in the release notes about how the foreign key dependency
stuff only works if they drop all current foreign keys (drop trigger)
and re-add them via alter table add foreign key is suggested.

Worst case scenario for Foreign keys is they will have what they always
had.

Dependency - have pg_dump auto-create dependencies when

loading 7.2.X

data?

Are we as far as we can go here?

The only trouble maker is foreign keys. If there was a nice way of
finding foreign keys in 7.2 and prior it probably would have been
implemented a long time ago in pg_dump :)

What about this.

1. Implement pg_get_foreignkey_def() or whatever
2. Adjust pg_dump to dump foreign keys using an ALTER statement
3. Back port the above to rel 7_2_2
4. Release a 7.2.2 version and ask that people upgrade to that version and
do a dump before they upgrade to 7.3.
5. All is well, plus ppl who don't want to switch to 7.3 on production get
all sorts of useful bug fixes as well.

Chris

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

remove interfaces/ssl if not improved

I am ready to yank this.

Agreed.

integrate or remove new libpqxx
integrate or add to gborg Pg:DBD

Seems like gborg is the place for these.

Yes, but I'd also like to see libpq++, perl5, and possibly some other
interfaces re-packaged separately. I think everyone agrees on the
direction here, it just needs someone (Marc?) to do the work.

allow specification of configuration files in a different directory?

Anyone working on this?

Not sure we need this for 7.3 -- unless (a) someone steps up to do the
work (b) there is some consensus on the design, I don't have a problem
with letting this wait for 7.4

Allow PL/PgSQL functions to return sets

Is anyone working on this?

I am. It should be ready in time for 7.3.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

On Thu, 2002-08-15 at 00:01, Christopher Kings-Lynne wrote:

Dependency - have pg_dump auto-create dependencies when

loading 7.2.X

data?

Are we as far as we can go here?

The only trouble maker is foreign keys. If there was a nice way of
finding foreign keys in 7.2 and prior it probably would have been
implemented a long time ago in pg_dump :)

What about this.

1. Implement pg_get_foreignkey_def() or whatever

I've done the parsing of foreign key triggers required in the past for
various documentation purposes and it wasn't overly fun -- nor am I sure
it's right in all cases.

Find 3 triggers with is_constraint true between two tables that match
argument sets, split argument list by comma, first 4 aren't so useful,
the rest in pairs are source / destination columns. Foreign Key state
(deferred, match, etc.) is in the function naming convention.

If you want to give it a shot, feel free. Whatever method is in place
will need to work on 7.3 for those who didn't use a newer pg_dump on the
older database.

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

What about this.
1. Implement pg_get_foreignkey_def() or whatever
2. Adjust pg_dump to dump foreign keys using an ALTER statement
3. Back port the above to rel 7_2_2
4. Release a 7.2.2 version and ask that people upgrade to that version and
do a dump before they upgrade to 7.3.

The trouble with this is that 7.2.2 would include a lot of rather poorly
tested code (code that has not even made it to CVS yet) ... and if
there's a problem in that code, it breaks dump files whether you are an
early upgrader to 7.3 or not.

I think that's likely to be a hard sell. The most we are likely to get
is to ask people to use the 7.3 pg_dump to dump their 7.2 server when
they are about to upgrade to 7.3 --- even that much is a difficult trick
for RPM users.

The other problem is that given a 7.2 system catalog setup, it's not
really any easier to reconstruct "this is a foreign key" on the server
side than it is to do it on the pg_dump side. So if we can figure out
how to do it at all, we might as well make pg_dump do the work instead
of insisting on a server update.

regards, tom lane

Bruce Momjian wrote:

Point-in-time recovery - ready for 7.3?

This seems very unlikely now. Status?

It would be a shame to have to wait for 7.4 for this one.

glibc and mktime() - fix?

I can do the work on this I need more info and no one seems to be
conerned.

I'm concerned, but in the few moments I've had to play with this, what
looked like the obvious fix didn't seem to work (I was hacking on glibc
itself though).

Allow PL/PgSQL functions to return sets

Is anyone working on this? We will get beaten up if we don't have this
for 7.3 and it is available in other languages.

I saw Neil's response. I'll jump in to help if he needs any.

Fix bytea to not encode input string

Not sure we can do these.

As I said, it isn't clear to me how this can be fixed without a fe/be
protocol change. But if someone can point me in the direction of a
viable fix for 7.3, I'll dive in.

Joe

Joe Conway <mail@joeconway.com> writes:

Bruce Momjian wrote:

Point-in-time recovery - ready for 7.3?

This seems very unlikely now. Status?

It would be a shame to have to wait for 7.4 for this one.

If a credible patch appears before the end of the month, great ---
but the discussions so far have left me feeling that we're still
a ways away from PITR. And I *don't* want to hold up 7.3 to wait
for it. Learned that lesson with WAL for 7.1 ...

glibc and mktime() - fix?

I can do the work on this I need more info and no one seems to be
conerned.

I'm concerned, but in the few moments I've had to play with this, what
looked like the obvious fix didn't seem to work (I was hacking on glibc
itself though).

Red Hat's internal opinion seems to be that "#define NO_MKTIME_BEFORE_1970"
is a sufficient answer. I consider that well to the south of sucking,
but at this point I really doubt that we have the time to implement a
better answer for 7.3. A better answer seems to mean writing our own
interface to the zic timezone database. Make no mistake: I think we
should do that, and will do it eventually. I just doubt it'll happen
in the next two weeks. And again, I do not feel we should hold up 7.3
to wait for a solution.

regards, tom lane

Christopher Kings-Lynne wrote:

[ ... ]

What about this.

1. Implement pg_get_foreignkey_def() or whatever
2. Adjust pg_dump to dump foreign keys using an ALTER statement
3. Back port the above to rel 7_2_2
4. Release a 7.2.2 version and ask that people upgrade to that version and
do a dump before they upgrade to 7.3.
5. All is well, plus ppl who don't want to switch to 7.3 on production get
all sorts of useful bug fixes as well.

If we have to have a 7.2.2 release, I'd like to suggest to backport
"create or replace view" , it it doesn't use any 7.3-specific feature.
This one is my pet peeve at the moment ... ;-) Would give a *lot* of
end-user functionality (and I am a and-user, after all), at little cost,
if I'm not mistaken ...).

--
Emmanuel Charpeentier

On Thu, Aug 15, 2002 at 12:09:00AM -0400, Neil Conway wrote:

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

...

integrate or remove new libpqxx
integrate or add to gborg Pg:DBD

Seems like gborg is the place for these.

Yes, but I'd also like to see libpq++, perl5, and possibly some other
interfaces re-packaged separately. I think everyone agrees on the
direction here, it just needs someone (Marc?) to do the work.

Would the method of use be
- checkout postgresql
- cd pgsql/src/interfaces
- checkout libpq++ from gborg
- cd ../..
- configure --with-CXX

or would libpq++ become more removed.. (configure options to libpq++ to
point to the rest or pgsql?)

Cheers,

Patrick
(prefer former)

On Thursday 15 August 2002 12:28 am, Tom Lane wrote:

I think that's likely to be a hard sell. The most we are likely to get
is to ask people to use the 7.3 pg_dump to dump their 7.2 server when
they are about to upgrade to 7.3 --- even that much is a difficult trick
for RPM users.

It's more of a difficult trick for the RPM maintainer.... :-)

No, I've thought about this possibility, and I can see packaging a
'postgresql-pg_dump73-7.2.1' RPM consisting entirely of the 7.3 pg_dump
linked against the pieces of 7.2.1 necessary. Ugly, but doable.

I know I sound like a broken record (for those who remember vinyl records),
but good upgrading tools would eliminate this recurring problem. That's all
I'm saying about that this time -- I've said enough, and it's all archived
for those who care to know what I think about the state of upgrading.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Actually, my _big_ question is whether the lack of dependency info
coming from 7.2 is going to cause problems in 7.3, i.e. do we make
assumptions that dependency info is there and in cases it isn't, are
there surprises for users, where things worked fine in 7.2. I want to
know if there are cases where we assumed dependency info was there when
in 7.2 we handled the lack of depenency better.

---------------------------------------------------------------------------

Tom Lane wrote:

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

What about this.
1. Implement pg_get_foreignkey_def() or whatever
2. Adjust pg_dump to dump foreign keys using an ALTER statement
3. Back port the above to rel 7_2_2
4. Release a 7.2.2 version and ask that people upgrade to that version and
do a dump before they upgrade to 7.3.

The trouble with this is that 7.2.2 would include a lot of rather poorly
tested code (code that has not even made it to CVS yet) ... and if
there's a problem in that code, it breaks dump files whether you are an
early upgrader to 7.3 or not.

I think that's likely to be a hard sell. The most we are likely to get
is to ask people to use the 7.3 pg_dump to dump their 7.2 server when
they are about to upgrade to 7.3 --- even that much is a difficult trick
for RPM users.

The other problem is that given a 7.2 system catalog setup, it's not
really any easier to reconstruct "this is a foreign key" on the server
side than it is to do it on the pg_dump side. So if we can figure out
how to do it at all, we might as well make pg_dump do the work instead
of insisting on a server update.

regards, tom lane

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

coming from 7.2 is going to cause problems in 7.3, i.e. do we make
assumptions that dependency info is there and in cases it isn't, are
there surprises for users, where things worked fine in 7.2. I want to
know if there are cases where we assumed dependency info was there when
in 7.2 we handled the lack of depenency better.

No, we have not broken any cases that used to work, AFAIK.

There are new features in 7.3 that will not work in a database made from
a 7.2 dump --- for example, dropping an old table containing a serial
column won't make the sequence go away, because we won't have a
dependency link between the table and the sequence. But it didn't go
away in 7.2 either, so the behavior's no worse. Another thing we won't
understand is that certain sets of triggers make up a foreign-key
constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to
delete 'em. But you couldn't in 7.2 either.

While I've toyed with the notion of trying to intuit these dependencies
as we reload a database, I'm not at all sure it's a good idea. The
former 7.2 user might be quite unhappy if we drop a sequence he wasn't
expecting to have dropped. We cannot tell for certain how the sequence
was made --- it might have been handmade and then used in an explicit
DEFAULT expression, in which case an auto-drop dependency would probably
not be a friendly thing to spring on the user.

The bulk of the new dependencies are made automatically as we handle
CREATE statements, so they'll be correct in a reloaded database anyway.
AFAIR it's just serial sequences and foreign keys that are not going to
be as bright as they might be.

regards, tom lane

Tom Lane wrote:

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

coming from 7.2 is going to cause problems in 7.3, i.e. do we make
assumptions that dependency info is there and in cases it isn't, are
there surprises for users, where things worked fine in 7.2. I want to
know if there are cases where we assumed dependency info was there when
in 7.2 we handled the lack of depenency better.

No, we have not broken any cases that used to work, AFAIK.

There are new features in 7.3 that will not work in a database made from
a 7.2 dump --- for example, dropping an old table containing a serial
column won't make the sequence go away, because we won't have a
dependency link between the table and the sequence. But it didn't go
away in 7.2 either, so the behavior's no worse. Another thing we won't
understand is that certain sets of triggers make up a foreign-key
constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to
delete 'em. But you couldn't in 7.2 either.

While I've toyed with the notion of trying to intuit these dependencies
as we reload a database, I'm not at all sure it's a good idea. The
former 7.2 user might be quite unhappy if we drop a sequence he wasn't
expecting to have dropped. We cannot tell for certain how the sequence
was made --- it might have been handmade and then used in an explicit
DEFAULT expression, in which case an auto-drop dependency would probably
not be a friendly thing to spring on the user.

The bulk of the new dependencies are made automatically as we handle
CREATE statements, so they'll be correct in a reloaded database anyway.
AFAIR it's just serial sequences and foreign keys that are not going to
be as bright as they might be.

OK, that's what I needed to know. It may be confusing to some users
that 7.2 serial/foreign keys don't auto-drop while 7.3 do. We need to
mention that in the release notes. I think that will be enough, but I
can imagine people dumping/reloading their db's to get that dependency,
and I am not sure how we would tell them to do that.

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

Socket permissions - only install user can access db by default
unix_socket_permissions in postgresql.conf

This is dead.

glibc and mktime() - fix?

Leave it be. If someone really needs time information from before 1970
(and who does?) he wouldn't use an OS that doesn't support it anyway.
There are several platforms that don't have complete time information
before 1947 and we've lived with those, too.

ecpg and bison issues - solved?

A release is cooking. 1.49b was released just a few days ago. Assuming
that it is sane and no final release comes out before beta, we might ship
our beta built with their beta and coordinate with them to make a final
release during our beta. It's a bit risky, but the more testing we can
provide to them the faster they will get a release out.

fix BeOS and QNX4 ports

Should we ship 7.3 without these ports?

Porters usually appear during beta.

integrate or remove new libpqxx
integrate or add to gborg Pg:DBD

Seems like gborg is the place for these.

I would volunteer to package libpq++ separately.

move pg_resetxlog and pg_controldata to main tree, add -f flag

That is me. I will get to it.

What does -f do?

--
Peter Eisentraut peter_e@gmx.net

Bruce Momjian wrote:

Allow PL/PgSQL functions to return sets

Is anyone working on this? We will get beaten up if we don't have this
for 7.3 and it is available in other languages.

That's true. I think I have to do this one. I'm busy for the next 2-3
weeks (Mom will be back from her Westcoast trip tonight and stay for
another 3 weeks). But I should be able to do something after that.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Jan Wieck wrote:

Bruce Momjian wrote:

Allow PL/PgSQL functions to return sets

Is anyone working on this? We will get beaten up if we don't have this
for 7.3 and it is available in other languages.

That's true. I think I have to do this one. I'm busy for the next 2-3
weeks (Mom will be back from her Westcoast trip tonight and stay for
another 3 weeks). But I should be able to do something after that.

Nope. We are in beta then. Either someone else will have to do it or
it will wait for 7.4.

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

OK, I removed this 7.3 open item and added a documentation item for the
release notes:

Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables

---------------------------------------------------------------------------

Rod Taylor wrote:

Dependency - have pg_dump auto-create dependencies when loading 7.2.X
data?

Are we as far as we can go here?

The only trouble maker is foreign keys. If there was a nice way of
finding foreign keys in 7.2 and prior it probably would have been
implemented a long time ago in pg_dump :)

Something in the release notes about how the foreign key dependency
stuff only works if they drop all current foreign keys (drop trigger)
and re-add them via alter table add foreign key is suggested.

Worst case scenario for Foreign keys is they will have what they always
had.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

Neil Conway wrote:

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

remove interfaces/ssl if not improved

I am ready to yank this.

Agreed.

Done and item removed.

allow specification of configuration files in a different directory?

Anyone working on this?

Not sure we need this for 7.3 -- unless (a) someone steps up to do the
work (b) there is some consensus on the design, I don't have a problem
with letting this wait for 7.4

Removed. No one has jumped on this. Added to TODO:

* Allow configuration files to be specified in a different directory

Allow PL/PgSQL functions to return sets

Is anyone working on this?

I am. It should be ready in time for 7.3.

OK.

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

Fix bytea to not encode input string

Not sure we can do these.

As I said, it isn't clear to me how this can be fixed without a fe/be
protocol change. But if someone can point me in the direction of a
viable fix for 7.3, I'll dive in.

OK, item removed and added to TODO:

* Prevent mismatch of frontend/backend encodings from converting bytea
data from being interpreted as encoded strings

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