Re: Open 7.3 issues

Here are some comments on the open 7.3 items. We have to start pairing
this down if we are going to hit beta in 2.5 weeks:

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

P O S T G R E S Q L

7 . 3 O P E N I T E M S

Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

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

Are we going to do anything with sockets permissions to tighten things up?
I know of one big client where PostgreSQL got a bad rap for being open
to all local users by default.

Point-in-time recovery - ready for 7.3?

This seems very unlikely now. Status?

Allow easy display of usernames in a group (pg_hba.conf uses groups now)

I was hoping for something on this because we are now using groups for
pg_hba.conf. If not, we can add it to TODO. I think it is already
there.

Reindex/btree shrinkage - does reindex need work, can btree be shrunk?

Can we do anything here?

display locks - ready?

This one is waiting to be applied.

Win32 - timefame?

Seems like a non-issue for 7.3.

Prepared statements - ready?

New version submitted recently. Is it ready to be applied?

Schema handling - ready? interfaces? client apps?

We need a posting describing what interfaces/applictions need to look at
for schemas.

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

Are we as far as we can go here?

glibc and mktime() - fix?

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

ecpg and bison issues - solved?

Do we have a fallback position on this if bison can't get a fixed
version?

improve macros in new tuple header code
have pg_dumpall dump out db privilege and per-user/db settings

These need to be done.

fix BeOS and QNX4 ports

Should we ship 7.3 without these ports?

fix implicit type coercions that are worse

Details?

remove interfaces/ssl if not improved

I am ready to yank this.

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

Seems like gborg is the place for these.

allow specification of configuration files in a different directory?

Anyone working on this?

handle lack of secondary passwords?

We are discussing this so I think we can get this done soon.

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

That is me. I will get to it.

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.

Fix bytea to not encode input string
Fix db, function, language permissions on 7.2 database loads

Not sure we can do these.

Agree on PGXLOG/-X handling

This is still an open item.

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

> 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(at)candle(dot)pha(dot)pa(dot)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(at)rogers(dot)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(at)familyhealth(dot)com(dot)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(at)joeconway(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)familyhealth(dot)com(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)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(at)Yahoo(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> > 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.

So everyone's conclusion is that we can't patch over this problem with a
patched up version on the link line, so I will just add it to the TODO
list:

* Fix glibc's mktime() to handle pre-1970's dates

Do we have a way to detect this bug and warn users somehow?

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

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Socket permissions - only install user can access db by default
> > unix_socket_permissions in postgresql.conf
>
> This is dead.

Removed, still on TODO.

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

Removed. Added to TODO.

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

We will see...

>
> > fix BeOS and QNX4 ports
> >
> > Should we ship 7.3 without these ports?
>
> Porters usually appear during beta.

Well, we don't really want porting fixes during beta unless we can help
it. ;-)

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

There is concern that using pg_resetxlog by accident could cause
problems, so it will prompt the user for confirmation by default. -f
(force) disables that confirmation.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> writes:
>> What does -f do?

> There is concern that using pg_resetxlog by accident could cause
> problems, so it will prompt the user for confirmation by default. -f
> (force) disables that confirmation.

pg_resetxlog already has an -f switch, and I do not think you should
change its semantics. At least not without putting up a better argument
than the above. Anyone who's running pg_resetxlog had already better
know what they're doing.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> What does -f do?
>
> > There is concern that using pg_resetxlog by accident could cause
> > problems, so it will prompt the user for confirmation by default. -f
> > (force) disables that confirmation.
>
> pg_resetxlog already has an -f switch, and I do not think you should
> change its semantics. At least not without putting up a better argument
> than the above. Anyone who's running pg_resetxlog had already better
> know what they're doing.

I hadn't looked at flags yet. Thomas's concern, and I think a valid
one, is that if we move it from contrib into the main tree, people may
accidentally run pg_resetxlog without understanding the issues involved.
We have it /contrib partly to make sure it isn't installed in the
default path for all admins.

What do people want? We can rethink this.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> writes:
> I hadn't looked at flags yet. Thomas's concern, and I think a valid
> one, is that if we move it from contrib into the main tree, people may
> accidentally run pg_resetxlog without understanding the issues involved.

There's already an interlock to prevent you from running it against a
live installation (it won't run if it sees a postmaster lock file).
That should also prevent an accidental run against a crashed installation
(presumably a lockfile will still be there). And if you run it against
a cleanly-shut-down installation, it's harmless because you don't need
the old xlog.

I don't think we need to be so paranoid as to insist that you say
pg_resetxlog --yes-i-read-the-manual
before it will do anything.

regards, tom lane

OK, sounds reasonable.

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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I hadn't looked at flags yet. Thomas's concern, and I think a valid
> > one, is that if we move it from contrib into the main tree, people may
> > accidentally run pg_resetxlog without understanding the issues involved.
>
> There's already an interlock to prevent you from running it against a
> live installation (it won't run if it sees a postmaster lock file).
> That should also prevent an accidental run against a crashed installation
> (presumably a lockfile will still be there). And if you run it against
> a cleanly-shut-down installation, it's harmless because you don't need
> the old xlog.
>
> I don't think we need to be so paranoid as to insist that you say
> pg_resetxlog --yes-i-read-the-manual
> before it will do anything.
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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 wrote:
>
> 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.

Since PL/pgSQL is a loadable module still, we might be able to provide
an upgrade after 7.3 is out instead of waiting for 7.4.

Jan

--

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

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Since PL/pgSQL is a loadable module still, we might be able to provide
> an upgrade after 7.3 is out instead of waiting for 7.4.

Maybe, but you'd have to get the core-code end of it in before beta.
AFAIR Joe's patch doesn't yet cover any return style from a function
except one-row-at-a-time.

regards, tom lane

Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>
>>Since PL/pgSQL is a loadable module still, we might be able to provide
>>an upgrade after 7.3 is out instead of waiting for 7.4.
>
>
> Maybe, but you'd have to get the core-code end of it in before beta.
> AFAIR Joe's patch doesn't yet cover any return style from a function
> except one-row-at-a-time.
>

Neil said he was working on this and expected to have it done for 7.3. I
think he's using the approach we discussed at OSCON, namely generating a
tuplestore within the plpgsql module and passing it back to FunctionNext.

Joe

Joe Conway wrote:
> Tom Lane wrote:
> > Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> >
> >>Since PL/pgSQL is a loadable module still, we might be able to provide
> >>an upgrade after 7.3 is out instead of waiting for 7.4.
> >
> >
> > Maybe, but you'd have to get the core-code end of it in before beta.
> > AFAIR Joe's patch doesn't yet cover any return style from a function
> > except one-row-at-a-time.
> >
>
> Neil said he was working on this and expected to have it done for 7.3. I
> think he's using the approach we discussed at OSCON, namely generating a
> tuplestore within the plpgsql module and passing it back to FunctionNext.

If I understand correctly, it is a great idea because it uses the cursor
return support already in pl/pgsql to handle it. Great idea.

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

On Thu, 15 Aug 2002, Peter Eisentraut wrote:

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

Okay, the procedure is simple, but where do we want to put this? Do we
want to move the extracted libraries over to gborg (would be my first
preference), or keep them in the core repository?

Regardless of which, the extraction is simple ... but if GBorg, if you go
over and make a project and let me know what it is, I can move the library
from our CVS repository straight over there, so that we lose no logs or
anything ... just let me know its created ...

Bruce, can you make a project for Pg::DBD?

Marc G. Fournier wrote:
> On Thu, 15 Aug 2002, Peter Eisentraut wrote:
>
> > > 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.
>
> Okay, the procedure is simple, but where do we want to put this? Do we
> want to move the extracted libraries over to gborg (would be my first
> preference), or keep them in the core repository?
>
> Regardless of which, the extraction is simple ... but if GBorg, if you go
> over and make a project and let me know what it is, I can move the library
> from our CVS repository straight over there, so that we lose no logs or
> anything ... just let me know its created ...
>
> Bruce, can you make a project for Pg::DBD?

OK, I am ready to do the work, but I would like to get a plan of where
we are going. I see in interfaces:

cli
ecpg
jdbc
libpgeasy
libpgtcl
libpq
libpq++
libpqxx
odbc
perl5
python

and we have Pg:DBD waiting to be added.

Now, I know one of Marc's goals is to have libpq as a stand-alone
tarball, but I thought we decided that this _didn't_ require it to be in
a separate CVS repository.

If we split these up based on activity, we have, in decreasing activity
order:

jdbc
odbc
libpq
libpqxx
cli
ecpg
libpq++
libpgtcl
python
libpgeasy
Pg:DBD
perl5

We already have separate web sites for jdbc and odbc, and they are in
our main CVS.

What goals do we have? Do we create gborg accounts for all/most of
these so releases can be made independently of the main server? Do we
move their CVS out of the main tree too?

I don't think we should judge libpqxx differently than the other
interfaces just because it is new. We should find a consistent solution
and apply that to all of these interfaces.

Let me add that odbc and jdbc have successfully made releases
independent of our server for over a year now.

I wonder if the best solution is to create gborg accounts for every
interface and keep them in our main CVS, and do independent releases
from there. Should we point to jdbc/odbc.postgresql.org from gborg?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> writes:
> Now, I know one of Marc's goals is to have libpq as a stand-alone
> tarball, but I thought we decided that this _didn't_ require it to be in
> a separate CVS repository.

Removing libpq is impossible since psql, pg_dump, etc all depend on it.

> I don't think we should judge libpqxx differently than the other
> interfaces just because it is new.

The fact that it is new is a strike against it, and the fact that it is
not integrated is a bigger strike against it.

I think we should move out libpqxx and libpq++ now, and also perl5 if
we are going to put DBD::Pg on gborg rather than in the main distro.
We want to ensure there is a level playing field for libpqxx and DBD::Pg.

jdbc and odbc should be moved if and only if their maintainers want it.

I'm not in a hurry to move the rest; they're small and don't generate
a lot of CVS traffic.

regards, tom lane

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> Bruce, can you make a project for Pg::DBD?

Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce
doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer)
and hasn't expressed any dissatisfaction with CPAN, I'm not sure why
you'd like to move the software to GBorg...

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

Neil Conway wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > Bruce, can you make a project for Pg::DBD?
>
> Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce
> doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer)
> and hasn't expressed any dissatisfaction with CPAN, I'm not sure why
> you'd like to move the software to GBorg...

Uh, I got OK from Edmund. I haven't talked to Jeffrey but I thought
someone else had. I thought he had just taken it over and was OK with
us handling it.

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

On Sat, 17 Aug 2002, Bruce Momjian wrote:

> OK, I am ready to do the work, but I would like to get a plan of where
> we are going. I see in interfaces:
>
> cli
> ecpg
> jdbc
> libpgeasy
> libpgtcl
> libpq
> libpq++
> libpqxx
> odbc
> perl5
> python
>
> and we have Pg:DBD waiting to be added.
>
> Now, I know one of Marc's goals is to have libpq as a stand-alone
> tarball, but I thought we decided that this _didn't_ require it to be in
> a separate CVS repository.

Ya, this one I had no problem with ... the only thing with libpq that I do
request is that it has its own configure so that it can be completely
standalone ... but, IMHO, if someone compiles the server, they are going
to need libpq, I just want to make sure taht if they want libpq, they
don't need the server ...

> If we split these up based on activity, we have, in decreasing activity
> order:
>
> jdbc
> odbc
> libpq
> libpqxx
> cli
> ecpg
> libpq++
> libpgtcl
> python
> libpgeasy
> Pg:DBD
> perl5
>
> We already have separate web sites for jdbc and odbc, and they are in
> our main CVS.
>
> What goals do we have? Do we create gborg accounts for all/most of
> these so releases can be made independently of the main server? Do we
> move their CVS out of the main tree too?

IMHO, yes ...

> Let me add that odbc and jdbc have successfully made releases
> independent of our server for over a year now.

Correct, so they should be the easiest to move out as well ...

> I wonder if the best solution is to create gborg accounts for every
> interface and keep them in our main CVS, and do independent releases
> from there. Should we point to jdbc/odbc.postgresql.org from gborg?

Chris has made code changes to GBorg to allow for this based on requests
from Dave Page (ie. PgAdminII) ... so there is no problems with that ...

As for keeping them in our main CVS, the more we put over onto GBorg, the
more it will get used, test, debugged, pounded and stabilized ... hell,
maybe some of the 'dead projects' that are on GBorg will come alive again
also if ppl are going to GBorg and find them, download them and hit the
authors for fixes :)

But, moving the interfaces over will at least give ppl a reason to go over
and see what is there ...

On Sat, 17 Aug 2002, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Now, I know one of Marc's goals is to have libpq as a stand-alone
> > tarball, but I thought we decided that this _didn't_ require it to be in
> > a separate CVS repository.
>
> Removing libpq is impossible since psql, pg_dump, etc all depend on it.
>
> > I don't think we should judge libpqxx differently than the other
> > interfaces just because it is new.
>
> The fact that it is new is a strike against it, and the fact that it is
> not integrated is a bigger strike against it.
>
> I think we should move out libpqxx and libpq++ now, and also perl5 if
> we are going to put DBD::Pg on gborg rather than in the main distro.
> We want to ensure there is a level playing field for libpqxx and DBD::Pg.
>
> jdbc and odbc should be moved if and only if their maintainers want it.
>
> I'm not in a hurry to move the rest; they're small and don't generate
> a lot of CVS traffic.

Note: I'm happy enough seeing ppl starting to consider moving this stuff
over to GBorg, I, by no means, expect everything to go overnight, or even
before v7.3 ...

As I mentioned in another message, I'm also kinda hoping that if we start
to divert traffic to GBorg for stuff like this, then some of the other
projects might 'come alive' again as well ...

Marc G. Fournier wrote:
> Chris has made code changes to GBorg to allow for this based on requests
> from Dave Page (ie. PgAdminII) ... so there is no problems with that ...
>
> As for keeping them in our main CVS, the more we put over onto GBorg, the
> more it will get used, test, debugged, pounded and stabilized ... hell,
> maybe some of the 'dead projects' that are on GBorg will come alive again
> also if ppl are going to GBorg and find them, download them and hit the
> authors for fixes :)
>
> But, moving the interfaces over will at least give ppl a reason to go over
> and see what is there ...

OK, so create gborg projects for all interfaces, and allow them to
release independently. I think we have agreement on that. It can only
be a win. That also gives us a mailing list and bug tracking for each
interface, which is nice.

I think the only unknown is whether their CVS's should be moved out of
the main tree.

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

On Sat, 17 Aug 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > Chris has made code changes to GBorg to allow for this based on requests
> > from Dave Page (ie. PgAdminII) ... so there is no problems with that ...
> >
> > As for keeping them in our main CVS, the more we put over onto GBorg, the
> > more it will get used, test, debugged, pounded and stabilized ... hell,
> > maybe some of the 'dead projects' that are on GBorg will come alive again
> > also if ppl are going to GBorg and find them, download them and hit the
> > authors for fixes :)
> >
> > But, moving the interfaces over will at least give ppl a reason to go over
> > and see what is there ...
>
> OK, so create gborg projects for all interfaces, and allow them to
> release independently. I think we have agreement on that. It can only
> be a win. That also gives us a mailing list and bug tracking for each
> interface, which is nice.
>
> I think the only unknown is whether their CVS's should be moved out of
> the main tree.

Yes, they should be ... maintaining sources in two places would be
'nightmarish' *and* at least GBorg will give a maintainer the ability to
add other developers to have CVS access as well, or transferrign
maintainership over to someone else ... GBorg is setup so that each
project has its own CVSROOT, and its own access controls ...

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>> I think the only unknown is whether their CVS's should be moved out of
>> the main tree.

> Yes, they should be ...

Certainly. I was a bit worried about losing CVS history, but Marc
indicated he could make the move with history and all, so there's
no downside.

regards, tom lane

On Sat, 17 Aug 2002, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> >> I think the only unknown is whether their CVS's should be moved out of
> >> the main tree.
>
> > Yes, they should be ...
>
> Certainly. I was a bit worried about losing CVS history, but Marc
> indicated he could make the move with history and all, so there's
> no downside.

Okay, here is what I'd like to suggest ... Bruce, let's start off really
simple ... go create a project for libpq++ (I believe someone even
volunteered to maintain it?) and let me know once created, and I'll move
the CVS directory over for libpq++ and out of the pgsql-server directory
...

On Fri, 16 Aug 2002, Bruce Momjian wrote:

> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > Socket permissions - only install user can access db by default
> > > unix_socket_permissions in postgresql.conf
> >
> > This is dead.
>
> Removed, still on TODO.

Daft question but isn't this an administrator's issue? Forcing a complete
override of umask isn't usually considered a decent, friendly thing to do and
the sys admin can change the permission bits.

Besides, what was the proposed scheme? user/group writable world not I presume.
I wouldn't even know how to port that to un unixy systems like Win32.

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> Daft question but isn't this an administrator's issue?

The feature wasn't going to change; the argument was just about whether
to change the factory-default permissions mask for the socket. An admin
could override the default in any case (and probably should, in many
cases).

The argument for 0700 was that it is "secure", the argument against
was that it's useless. No one sane runs their apps as the postgres
user, therefore you'd always be having to open it up anyway.

We thought a little about 0770 but the problem is that the actual
behavior is extremely context-dependent. On some Unixes this is
just what you want, on others it's little different from 0777.
In any case depending on group membership to control database access
means that the DBA *must* have root privileges, which is not an
assumption we like to make.

So unless someone comes up with a new idea, we're sticking with 0777
for backwards-compatibility reasons. But certainly socket permissions
ought to be on the short list of things to think about during every
database install.

regards, tom lane

Marc G. Fournier writes:

> Okay, here is what I'd like to suggest ... Bruce, let's start off really
> simple ... go create a project for libpq++ (I believe someone even
> volunteered to maintain it?) and let me know once created, and I'll move
> the CVS directory over for libpq++ and out of the pgsql-server directory

I said that I would lend a hand in preparing the build system, but I'm not
going to start a project on gborg if I have to agree to a two-page terms
of service agreement and I don't get to choose the exact wording of the
license.

I would prefer it if libpq++ would stay in the cvs tree at
cvs.postgresql.org. There's no point in starting an entirely new
infrastructure elsewhere.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Sun, 18 Aug 2002, Peter Eisentraut wrote:

> Marc G. Fournier writes:
>
> > Okay, here is what I'd like to suggest ... Bruce, let's start off really
> > simple ... go create a project for libpq++ (I believe someone even
> > volunteered to maintain it?) and let me know once created, and I'll move
> > the CVS directory over for libpq++ and out of the pgsql-server directory
>
> I said that I would lend a hand in preparing the build system, but I'm not
> going to start a project on gborg if I have to agree to a two-page terms
> of service agreement and I don't get to choose the exact wording of the
> license.

I didn't ask you to, I asked Bruce to ... and the license should stay BSD
...

Actually, I think Jeroen T. Vermeulen <jtv(at)xs4all(dot)nl> should create the
project. It is his code, and if he would add me as an admin, that would
help. I am CC'ing him.

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

Marc G. Fournier wrote:
> On Sun, 18 Aug 2002, Peter Eisentraut wrote:
>
> > Marc G. Fournier writes:
> >
> > > Okay, here is what I'd like to suggest ... Bruce, let's start off really
> > > simple ... go create a project for libpq++ (I believe someone even
> > > volunteered to maintain it?) and let me know once created, and I'll move
> > > the CVS directory over for libpq++ and out of the pgsql-server directory
> >
> > I said that I would lend a hand in preparing the build system, but I'm not
> > going to start a project on gborg if I have to agree to a two-page terms
> > of service agreement and I don't get to choose the exact wording of the
> > license.
>
> I didn't ask you to, I asked Bruce to ... and the license should stay BSD
> ...
>
>
>

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

We're talking about libpq++, not libpqxx :)

On Mon, 19 Aug 2002, Bruce Momjian wrote:

>
> Actually, I think Jeroen T. Vermeulen <jtv(at)xs4all(dot)nl> should create the
> project. It is his code, and if he would add me as an admin, that would
> help. I am CC'ing him.
>
>
> ---------------------------------------------------------------------------
>
> Marc G. Fournier wrote:
> > On Sun, 18 Aug 2002, Peter Eisentraut wrote:
> >
> > > Marc G. Fournier writes:
> > >
> > > > Okay, here is what I'd like to suggest ... Bruce, let's start off really
> > > > simple ... go create a project for libpq++ (I believe someone even
> > > > volunteered to maintain it?) and let me know once created, and I'll move
> > > > the CVS directory over for libpq++ and out of the pgsql-server directory
> > >
> > > I said that I would lend a hand in preparing the build system, but I'm not
> > > going to start a project on gborg if I have to agree to a two-page terms
> > > of service agreement and I don't get to choose the exact wording of the
> > > license.
> >
> > I didn't ask you to, I asked Bruce to ... and the license should stay BSD
> > ...
> >
> >
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>

Oh, sorry. I will do it now.

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

Marc G. Fournier wrote:
>
> We're talking about libpq++, not libpqxx :)
>
>
> On Mon, 19 Aug 2002, Bruce Momjian wrote:
>
> >
> > Actually, I think Jeroen T. Vermeulen <jtv(at)xs4all(dot)nl> should create the
> > project. It is his code, and if he would add me as an admin, that would
> > help. I am CC'ing him.
> >
> >
> > ---------------------------------------------------------------------------
> >
> > Marc G. Fournier wrote:
> > > On Sun, 18 Aug 2002, Peter Eisentraut wrote:
> > >
> > > > Marc G. Fournier writes:
> > > >
> > > > > Okay, here is what I'd like to suggest ... Bruce, let's start off really
> > > > > simple ... go create a project for libpq++ (I believe someone even
> > > > > volunteered to maintain it?) and let me know once created, and I'll move
> > > > > the CVS directory over for libpq++ and out of the pgsql-server directory
> > > >
> > > > I said that I would lend a hand in preparing the build system, but I'm not
> > > > going to start a project on gborg if I have to agree to a two-page terms
> > > > of service agreement and I don't get to choose the exact wording of the
> > > > license.
> > >
> > > I didn't ask you to, I asked Bruce to ... and the license should stay BSD
> > > ...
> > >
> > >
> > >
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

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

Done. Called libpq++.

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

Bruce Momjian wrote:
>
> Oh, sorry. I will do it now.
>
> ---------------------------------------------------------------------------
>
> Marc G. Fournier wrote:
> >
> > We're talking about libpq++, not libpqxx :)
> >
> >
> > On Mon, 19 Aug 2002, Bruce Momjian wrote:
> >
> > >
> > > Actually, I think Jeroen T. Vermeulen <jtv(at)xs4all(dot)nl> should create the
> > > project. It is his code, and if he would add me as an admin, that would
> > > help. I am CC'ing him.
> > >
> > >
> > > ---------------------------------------------------------------------------
> > >
> > > Marc G. Fournier wrote:
> > > > On Sun, 18 Aug 2002, Peter Eisentraut wrote:
> > > >
> > > > > Marc G. Fournier writes:
> > > > >
> > > > > > Okay, here is what I'd like to suggest ... Bruce, let's start off really
> > > > > > simple ... go create a project for libpq++ (I believe someone even
> > > > > > volunteered to maintain it?) and let me know once created, and I'll move
> > > > > > the CVS directory over for libpq++ and out of the pgsql-server directory
> > > > >
> > > > > I said that I would lend a hand in preparing the build system, but I'm not
> > > > > going to start a project on gborg if I have to agree to a two-page terms
> > > > > of service agreement and I don't get to choose the exact wording of the
> > > > > license.
> > > >
> > > > I didn't ask you to, I asked Bruce to ... and the license should stay BSD
> > > > ...
> > > >
> > > >
> > > >
> > >
> > > --
> > > Bruce Momjian | http://candle.pha.pa.us
> > > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > > + If your life is a hard drive, | 13 Roberts Road
> > > + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> > >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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