Open 7.3 items

Schema handling - ready? interfaces? client apps?

With schemas, how about settings for automatically creating a schema for a
user when you create the user, etc.

Chris

On Tuesday 30 July 2002 11:50 pm, Bruce Momjian wrote:

Here are the open items for 7.3. We have one more month to address them
before beta.

Source Code Changes
-------------------

Bruce, is the config file location stuff not being addressed? I remember Mark
(mlw) had worked up the patch for a '-C' switch, there was discussion, etc.
Did it not make the todo?

If Peter or someone else doesn't beat me to it I might try my hand at that
one, as I would dearly love to be able to decouple the config files from
PGDATA. It has been discussed; consensus was not reached as I recall.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen wrote:

On Tuesday 30 July 2002 11:50 pm, Bruce Momjian wrote:

Here are the open items for 7.3. We have one more month to address them
before beta.

Source Code Changes
-------------------

Bruce, is the config file location stuff not being addressed? I remember Mark
(mlw) had worked up the patch for a '-C' switch, there was discussion, etc.
Did it not make the todo?

If Peter or someone else doesn't beat me to it I might try my hand at that
one, as I would dearly love to be able to decouple the config files from
PGDATA. It has been discussed; consensus was not reached as I recall.

The issue was never resolved, so it did not make any lists.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Lamar Owen <lamar.owen@wgcr.org> writes:

Bruce, is the config file location stuff not being addressed? ...
If Peter or someone else doesn't beat me to it I might try my hand at that
one, as I would dearly love to be able to decouple the config files from
PGDATA. It has been discussed; consensus was not reached as I recall.

I believe that last part was the sticking point. If you can find some
consensus on how it ought to work, then go for it. My own opinion is
that there is nothing broken there; certainly nothing so broken that
we need to force a change under schedule pressure.

regards, tom lane

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

Bruce, is the config file location stuff not being addressed? ...
If Peter or someone else doesn't beat me to it I might try my hand at that
one, as I would dearly love to be able to decouple the config files from
PGDATA. It has been discussed; consensus was not reached as I recall.

I believe that last part was the sticking point. If you can find some
consensus on how it ought to work, then go for it. My own opinion is
that there is nothing broken there; certainly nothing so broken that
we need to force a change under schedule pressure.

I don't feel we are under pressure. We have time to discuss and address
it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

Tom Lane wrote:

... My own opinion is
that there is nothing broken there; certainly nothing so broken that
we need to force a change under schedule pressure.

I don't feel we are under pressure. We have time to discuss and address
it.

Well, it's all a matter of how you look at it. Isn't the point of your
post that began this thread to start giving people a sense of time
pressure?

I agree that if we could quickly come to a resolution about how this
ought to work, there's plenty of time to go off and implement it. But
(1) we failed to come to a consensus before, so I'm not optimistic
than one will suddenly emerge now; (2) we've got a ton of other issues
that we *need* to deal with before beta. This one does not strike me
as a must-fix, and so I'm loathe to spend much development time on it
when there are so many open issues.

regards, tom lane

Tom Lane wrote:

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

Tom Lane wrote:

... My own opinion is
that there is nothing broken there; certainly nothing so broken that
we need to force a change under schedule pressure.

I don't feel we are under pressure. We have time to discuss and address
it.

Well, it's all a matter of how you look at it. Isn't the point of your
post that began this thread to start giving people a sense of time
pressure?

I agree that if we could quickly come to a resolution about how this
ought to work, there's plenty of time to go off and implement it. But
(1) we failed to come to a consensus before, so I'm not optimistic
than one will suddenly emerge now; (2) we've got a ton of other issues
that we *need* to deal with before beta. This one does not strike me
as a must-fix, and so I'm loathe to spend much development time on it
when there are so many open issues.

Well, it is up to the individuals involved. If someone wants to deal
with it, and gets a consensus, and comes up with a patch, let them.

The list is for time pressure on those items. It does not affect new
items.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

Here are the open items for 7.3.

Some comments ...

Socket permissions - only install user can access db by default

I do not agree with this goal.

NAMEDATALEN - disk/performance penalty for increase, 64, 128?
FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?

At the moment I don't see a lot of solid evidence that increasing
NAMEDATALEN has any performance penalty. Someone reported about
a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway
tried to reproduce the result, and got about a 10% *speedup*.
Personally I think 10% is well within the noise spectrum for
pgbench, and so it's difficult to claim that we have established
any performance difference at all. I have not tried to measure
FUNC_MAX_ARGS differences.

Point-in-time recovery - ready for 7.3?

At the moment, it doesn't exist at all. If patches appear, we can
review 'em, but right now there is nothing to debate.

DROP COLUMN - ready?

I'm on it.

Win32 - timefame?

I've seen nothing to make me think this will be ready for 7.3.

Prepared statements - ready?

I think we're close there; the patch seems okay, we're just debating
minor syntax issues.

Schema handling - ready? interfaces? client apps?

The backend will be ready (it's not quite yet). pg_dump is ready.
psql is very definitely not ready, nor is pgaccess. I don't know the
status for JDBC or ODBC; any comments? The other interface libraries
probably don't care.

Dependency - pg_dump auto-create dependencies for 7.2.X data?

Huh?

glibc and mktime() - fix?

We need a fix for this. Dunno what to do about it.

ecpg and bison issues - solved?

Not yet :-(. Anyone have a line into the bison project?

Other things on my radar screen:

* I have about zero confidence in the recent tuple-header-size-reduction
patches.

* pg_conversion stuff --- do we understand this thing's behavior under
failure conditions? Does it work properly with namespaces and
dependencies?

* pg_dumpall probably ought to dump database privilege settings, also
per-user and per-database GUC settings.

* BeOS and QNX4 ports are busted.

* The whole area of which implicit coercions should be allowed is a
serious problem that we have not spent enough time on. There are
a number of cases in which CVS tip is clearly broken compared to
prior releases.

* Bear Giles' SSL patches seem to be causing unhappiness in some
quarters.

* libpqxx is not integrated into build process nor docs. It should
be integrated or reversed out before beta.

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, July 30, 2002 9:50 PM
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Open 7.3 items

[snip]

Win32 - timefame?

I may be able to contribute the Win32 stuff we have done here. (Not
sure of it, but they do seem more open to the idea now). It's only for
7.1.3, and so I am not sure how helpful it would be. There is also a
bunch of stuff that looks like this in the code:

#ifdef ICKY_WIN32_KLUDGE
/* Bletcherous hack to make it work in Win32 goes here... */
#else
/* Normal code goes here... */
#endif

Let me know if you are interested.

* pg_conversion stuff --- do we understand this thing's behavior under
failure conditions?

As far as I know, automatic encoding conversion behaves well under
failure conditions.

Does it work properly with namespaces and
dependencies?

Yes.
--
Tatsuo Ishii

add in 'fix pg_hba.conf / password issues' to that too :)

On Tue, 30 Jul 2002, Bruce Momjian wrote:

On Wed, 31 Jul 2002, Tom Lane wrote:

* libpqxx is not integrated into build process nor docs. It should
be integrated or reversed out before beta.

I've requestsed that Jeorgen(sp?) move this over to GBorg ... its
something that can, and should be, built seperately from the base
distribution, along with at least a dozen other things we have bloating
the distribution now :( but at least that one hasn't been integrated yet
...

We got into 'creeping featurisms' in the beginning because we had no other
really central location to put stuff ... we do now, and with better
mechanisms in place for dealing with 'multiple maintainers' ... its
about time we start to trim the fat, before we can't fit through the
proverbial door anymore ...

Peronally, I find it quite annoying to have to download the complete
server distribution just to get libpq installed so that I can install
mod_php4 ... and with all the talk about 'why mysql vs pgsql' that has
been going on lately, its time to start look at how to make it easier to
'add a new interface' without having to download the whole distribution
'yet again' ...

Dependency - pg_dump auto-create dependencies for 7.2.X data?

Huh?

Taking a bunch of CREATE CONSTRAINT TRIGGERS and turning them into the
proper pg_constraint entries...

Chris

...

I agree that if we could quickly come to a resolution about how this
ought to work, there's plenty of time to go off and implement it. But
(1) we failed to come to a consensus before, so I'm not optimistic
than one will suddenly emerge now; (2) we've got a ton of other issues
that we *need* to deal with before beta. This one does not strike me
as a must-fix, and so I'm loathe to spend much development time on it
when there are so many open issues.

afaict someone else volunteered to do the work. There is no lack of
consensus that this is a useful feature, at least among those who take
responsibility to package PostgreSQL for particular platforms. How about
letting them specify the requirements and if an acceptable solution
emerges soon, we'll have it for 7.3...

- Thomas

Schema handling - ready? interfaces? client apps?

status for JDBC or ODBC; any comments? The other interface libraries
probably don't care.

What about DBD::Pg?

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 �ben 12.00-18.00 Web: www.suse.dk
2000 Frederiksberg L�rdag 12.00-16.00 Email:kar@kakidata.dk

Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a écrit :

Source Code Changes

What about CREATE OR REPLACE VIEW which would be great for pgAdmin2. Thanks to
all of you./Jean-Michel POURE

I too do not like alot of bloat in the distribution, but I also agree
with what Andrew is saying.

Currently, at the FTP site, you can download the whole tar file, or in 4
separate tarballs. How hard would it be to create a separate tarball for
client related packages? I am not sure if this would be a *great*
solution, but it might be a good compromise.

--brett

On Wed, 2002-07-31 at 10:22, Andrew Sullivan wrote:

On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote:

On Wed, 31 Jul 2002, Tom Lane wrote:

One reason for wanting to integrate libpqxx is that I don't think we'll
find out anything about its portability until we get a lot of people
trying to build it. If it's a separate distro that won't happen quickly.

Who cares? Those that need a C++ interface will know where to find it,
and will report bugs that they have ... why should it be tested on every
platform when we *might* only have those on the Linux platform using it?

This seems a bad argument. You can't say "we support interface xyz"
and never test it on anything except i80x86 Linux. Somebady comes
along and tries to make it go on Solaris, and it doesn't work: poof,
the cross-platform reputation that you and other have worked hard to
burnish goes away. Never mind that it's only a client library.

Besides, more generally, Postgres already has a reputation as being
difficult to install. The proposal to separate out all the
"non-basics" (I'm not even sure how one would draw that line: maybe a
server-only package and a client-library package run through GBorg?)
would mean that anyone wanting to do something moderately complicated
would have a yet higher hurdle. Isn't that a problem?

A

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
+1 416 646 3304 x110

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Brett Schwarz
brett_schwarz AT yahoo.com

On Wed, Jul 31, 2002 at 02:11:06AM -0300, Marc G. Fournier wrote:

On Wed, 31 Jul 2002, Tom Lane wrote:

* libpqxx is not integrated into build process nor docs. It should
be integrated or reversed out before beta.

I've requestsed that Jeorgen(sp?) move this over to GBorg ... its
something that can, and should be, built seperately from the base
distribution, along with at least a dozen other things we have bloating
the distribution now :( but at least that one hasn't been integrated yet
...

Mentioning that on -hackers would have been nice -- I've spent a while
this week hacking autoconf / Makefiles to integrate libpqxx...

The problem I have with removing libpqxx is that libpq++ is a far
inferior C++ interface. If we leave libpq++ as the only C++ interface
distributed with PostgreSQL, there will be a tendancy for people
using PostgreSQL & C++ to use the C++ support included with the
distribution. Similarly, the Perl interface included with
PostgreSQL is widely regarded as inferior to DBD::Pg.

If we're going to start removing interfaces, I'd vote for the removal of
perl5 & libpq++ as well as libpqxx. We can add a section to the
documentation listing the available language interfaces (for languages
like Python, where several interfaces exist, this would probably be a
good idea anyway).

Cheers,

Neil

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

nconway@klamath.dyndns.org (Neil Conway) writes:

Mentioning that on -hackers would have been nice -- I've spent a while
this week hacking autoconf / Makefiles to integrate libpqxx...

Marc's opinion is not the same thing as a done deal ;-) --- we still
have to discuss this, and if someone's already doing the integration
work I think that's an important factor.

If we're going to start removing interfaces, I'd vote for the removal of
perl5 & libpq++ as well as libpqxx.

Agreed on that point. We shouldn't be promoting old, crufty interface
libraries when there are better ones available.

I would personally prefer to see libpqxx integrated now, and then we
could plan to remove libpq++ in a release or two (after giving people
a reasonable opportunity to switch over). If anyone still cares about
libpq++ at that point, it could be given a home on gborg.

One reason for wanting to integrate libpqxx is that I don't think we'll
find out anything about its portability until we get a lot of people
trying to build it. If it's a separate distro that won't happen quickly.

regards, tom lane