Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] 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,
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 [EMAIL PROTECTED] should
Done. Called libpq++.
---
Bruce Momjian wrote:
Oh, sorry. I will do it now.
---
Marc G. Fournier wrote:
We're talking about libpq++,
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
Nigel J. Andrews [EMAIL PROTECTED] 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
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
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
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
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
Bruce Momjian [EMAIL PROTECTED] 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
Marc G. Fournier [EMAIL PROTECTED] 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
Neil Conway wrote:
Marc G. Fournier [EMAIL PROTECTED] 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
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
On Sat, 17 Aug 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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,
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
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
Marc G. Fournier [EMAIL PROTECTED] 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
On Sat, 17 Aug 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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,
Bruce Momjian [EMAIL PROTECTED] 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
OK, sounds reasonable.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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,
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.
Jan Wieck [EMAIL PROTECTED] 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
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] 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
Joe Conway wrote:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] 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
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
On Thu, Aug 15, 2002 at 12:09:00AM -0400, Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
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
Bruce Momjian [EMAIL PROTECTED] 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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
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
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
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] 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
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
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
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
Bruce Momjian [EMAIL PROTECTED] 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
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
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
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
Bruce Momjian [EMAIL PROTECTED] 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
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
Christopher Kings-Lynne [EMAIL PROTECTED] 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
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
Joe Conway [EMAIL PROTECTED] 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
47 matches
Mail list logo
