Done. Called libpq++.
---
Bruce Momjian wrote:
>
> Oh, sorry. I will do it now.
>
> ---
>
> Marc G. Fournier wrote:
> >
> > We're talking about li
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]
We're talking about libpq++, not libpqxx :)
On Mon, 19 Aug 2002, Bruce Momjian wrote:
>
> 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.
>
>
> -
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
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 mov
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 p
"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 prob
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
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
"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'
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 GBor
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, poun
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
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
> pe
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 dissatisfa
"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 w
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
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 simpl
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
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 bet
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
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
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 h
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 <[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 prev
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
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
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
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
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
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?
>
> N
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
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 ne
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 wo
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 a
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
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
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 m
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 po
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
> d
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 discussion
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
"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 versi
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 k
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++, per
> > 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 ti
> 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 p
47 matches
Mail list logo
