On Wed, 31 Jul 2002, Thomas Lockhart wrote:
> ...
> > *Eventually*, a simple checkout of 'pgsql' should result in a "server
> > only" distribution that we can pull bits and pieces into transparently ...
>
> I'm still not quite sure where this is headed or why, but if nothing
> else pgsql could an
On Thu, 1 Aug 2002, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Until we have folks who are excited enough about it to plan it out and
> > do the work, piecemeal rejection of components is not leading to a more
> > solid product.
>
> I'm lukewarm about whether to actually do
...
> *Eventually*, a simple checkout of 'pgsql' should result in a "server
> only" distribution that we can pull bits and pieces into transparently ...
I'm still not quite sure where this is headed or why, but if nothing
else pgsql could and should be the whole thing, and pgsql-server could
be t
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Until we have folks who are excited enough about it to plan it out and
> do the work, piecemeal rejection of components is not leading to a more
> solid product.
I'm lukewarm about whether to actually do the split or not ... but for
sure I agree with
> > * 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
OK, I have attached a patch for testing. Sample output is:
$ sql -U guest test
psql: FATAL: user "test.guest" does not exist
$ createuser test.guest
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more n
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Well, you can do get_namespace_name(rel->rd_rel->relnamespace), but
>> I don't really agree with changing error messages to *always* quote
>> the schema name. I think that'd be overly verbose.
> The problem I see is that imagine you're bro
On Thu, 1 Aug 2002, Tom Lane wrote:
> But that isn't an "equivalent query". You've manually transformed
> SELECT * FROM (SELECT something UNION SELECT somethingelse) WHERE foo;
> into
> (SELECT something WHERE foo) UNION (SELECT somethingelse WHERE foo);
Right.
> As has been pointed ou
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > If you have RelationGetRelationName(rel) to get the name of a
> relation, how
> > do you get it's fully qualified schema name? Or how do I get the schema
> > name for the relation?
>
> Well, you can do get_namespace_name(rel->rd_rel->rel
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Thu, 1 Aug 2002, Tom Lane wrote:
>> Curt Sampson <[EMAIL PROTECTED]> writes:
> You want to be careful with this sort of stuff, since the query planner
> sometimes won't do the view as efficiently as it would do the fully
> specified equivalant query. I
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> If you have RelationGetRelationName(rel) to get the name of a relation, how
> do you get it's fully qualified schema name? Or how do I get the schema
> name for the relation?
Well, you can do get_namespace_name(rel->rd_rel->relnamespace), b
On Thu, 1 Aug 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > You want to be careful with this sort of stuff, since the query planner
> > sometimes won't do the view as efficiently as it would do the fully
> > specified equivalant query. I've posted about this here before.
>
Marc G. Fournier wrote:
> Okay, final request .. how hard would it be to pre-pend the current
> database name if GUC value is on? ie. if I'm in db1 and run CREATE USER,
> it will add db1. to the username if I hadn't already? Sounds to me it
> would be simple to do, and it would "fix" the point
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > > > Access to nothing. I could actually try to quality by dbname.username,
> > > > > then fall back to just username, but that seems insecure.
Neil Conway wrote:
> On Wed, Jul 31, 2002 at 11:40:43PM -0400, Bruce Momjian wrote:
> > > Also, what happens if I enable the GUC var, create a bunch of different
> > > users/databases, and then disable it again?
> >
> > You swap back and forth between users with prepended dbnames and those
> > wi
On Wed, Jul 31, 2002 at 11:40:43PM -0400, Bruce Momjian wrote:
> > Also, what happens if I enable the GUC var, create a bunch of different
> > users/databases, and then disable it again?
>
> You swap back and forth between users with prepended dbnames and those
> withouth.
And if I've created th
thanks for the heads up, fixed ... part of the generation code was flawed,
in that it tried to move a directory that didn't exist, failed and exited
the script *roll eyes* added in an 'if' to make sure the directory
exists, and am running it manually now ...
On Wed, 31 Jul 2002, bpalmer wrote:
Curt Sampson <[EMAIL PROTECTED]> writes:
> You want to be careful with this sort of stuff, since the query planner
> sometimes won't do the view as efficiently as it would do the fully
> specified equivalant query. I've posted about this here before.
Please provide an example. AFAIK a view is a
Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > > Access to nothing. I could actually try to quality by dbname.username,
> > > > then fall back to just username, but that seems insecure.
> > >
> > > No, that's cool ... just questions I thou
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > Access to nothing. I could actually try to quality by dbname.username,
> > > then fall back to just username, but that seems insecure.
> >
> > No, that's cool ... just questions I thought of ...
>
> OK.
>
> > Okay ... hmmm
I've just updated the README.cvsup file in order to reflect the changes,
to provide a sample of how to download the whole thing, as well as
instructions on how to do "just" a particular module:
[ Updated README.cvsup ]=
# This file represents the s
Are snapshots still being generated on ftp.postgresql.org (and rsync)?
I've just noticed that the date for the last /dev/*-snapshot* is May 8th.
What's the deal?
- Brandon
c: 917-697-8665
Neil Conway wrote:
> On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote:
> > OK, I have thought about this. First, a possible solution would be to
> > have a GUC variable that prepends the dbname to all username
> > specifications, so the username becomes dbname.username. When you
> >
On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote:
> OK, I have thought about this. First, a possible solution would be to
> have a GUC variable that prepends the dbname to all username
> specifications, so the username becomes dbname.username. When you
> CREATE USER "test", it actua
Marc G. Fournier wrote:
> > Access to nothing. I could actually try to quality by dbname.username,
> > then fall back to just username, but that seems insecure.
>
> No, that's cool ... just questions I thought of ...
OK.
> Okay ... hmmm ... just making sure that I understand ... I setup a serv
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > I am working on it now. I decided against doing any kind of database
> > > prepending at the user level. You create the user as 'dbname.username'.
> > > That is clearer, rather than prepending based on the db you are
> >
Curt Sampson wrote:
> On Wed, 31 Jul 2002, Andrew Sullivan wrote:
>
> > Ok, how then would one set the location of the config file?
>
> Option on the command line. Works for lots of different servers out
> there already (BIND, apache, etc.).
>
> Whether we also want to emulate them using a comp
Marc G. Fournier wrote:
> > I am working on it now. I decided against doing any kind of database
> > prepending at the user level. You create the user as 'dbname.username'.
> > That is clearer, rather than prepending based on the db you are
> > connected to. The only code change is in the postm
On Wed, 31 Jul 2002, Peter Eisentraut wrote:
> But the location of the WAL logs, and the commit logs, if anyone is
> thinking in that direction, needs to be known to initdb. And if you want
> to move them later you'd need to halt the entire system
I don't see this as a big problem. Right no
On Wed, 31 Jul 2002, Andrew Sullivan wrote:
> Ok, how then would one set the location of the config file?
Option on the command line. Works for lots of different servers out
there already (BIND, apache, etc.).
Whether we also want to emulate them using a compiled-in default if the
command line
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > > >
> > > > > Ron Snyder wrote:
> > > > > > >
> > > > > > > Yes, is that your pg_hba.conf line?
Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > >
> > > > Ron Snyder wrote:
> > > > > >
> > > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over
> > > > > > networks you don't
If you have RelationGetRelationName(rel) to get the name of a relation, how
do you get it's fully qualified schema name? Or how do I get the schema
name for the relation?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> >
> > > Ron Snyder wrote:
> > > > >
> > > > > Yes, is that your pg_hba.conf line? 'password' is insecure over
> > > > > networks you don't trust.
> > > >
> > > > Yes, we're using '
Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > Ron Snyder wrote:
> > > >
> > > > Yes, is that your pg_hba.conf line? 'password' is insecure over
> > > > networks you don't trust.
> > >
> > > Yes, we're using 'password password' in our pg_hba.conf file. I trust my
> >
On Thu, 1 Aug 2002, Christopher Kings-Lynne wrote:
> > Okay ... since this is pretty much going to be 'one camp for, one camp
> > against' without anything to really back up either camps perspectives /
> > arguments, I did some research on CVS in order to find a nice, effective
> > middle ground
How do I find the current username a query is running as from within the
backend? I'm thinking of improving the permission denied errors a bit...
I see GetUserId(), but how do I get a char* of the username...
Chris
---(end of broadcast)---
TIP 1
> > As for 7.3, maybe we can get that done in time of everyone likes it.
> > If we can't, what do we do? Do we re-add the secondary password file
> > stuff that most people don't like? My big question is how many other
> > PostgreSQL users figured out they could use the secondary password file
>
> Okay ... since this is pretty much going to be 'one camp for, one camp
> against' without anything to really back up either camps perspectives /
> arguments, I did some research on CVS in order to find a nice, effective
> middle ground ... and it actually works quite sweet ...
Personally, I'd l
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> Ron Snyder wrote:
> > >
> > > Yes, is that your pg_hba.conf line? 'password' is insecure over
> > > networks you don't trust.
> >
> > Yes, we're using 'password password' in our pg_hba.conf file. I trust my
> > network (so far).
>
> That is another ma
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> One idea I had was to look for a colon in the username, and if I see
> one, I assume everything after the colon is a password. Would that work
> for you?
That would definitely work ... but I *really* like your GUC idea ... it
would allow ppl to change
On Wed, 31 Jul 2002, Bruce Momjian wrote:
> OK, I have thought about this. First, a possible solution would be to
> have a GUC variable that prepends the dbname to all username
> specifications, so the username becomes dbname.username. When you
> CREATE USER "test", it actually does CREATE USER
> Is there a catalog to track those
> psql processes - what their functions, who
> issues, etc.?
>
> thanks.
>
> johnl
If you have it enabled in your postgresql.conf, just go:
select * from pg_stat_activity;
Chris
---(end of broadcast)---
TI
Okay ... since this is pretty much going to be 'one camp for, one camp
against' without anything to really back up either camps perspectives /
arguments, I did some research on CVS in order to find a nice, effective
middle ground ... and it actually works quite sweet ...
Basically, CVS let's you
> 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
On Wed, 31 Jul 2002, Zeugswetter Andreas SB SD wrote:
> The utility is "Table Partitioning by expression".
>
> Basically you have a union view like:
> create view history as
> select * from history2000 where yearcol=2000
> union all
> select * from history2001 where yearcol=2001
You want to be c
Ron Snyder wrote:
> >
> > Yes, is that your pg_hba.conf line? 'password' is insecure over
> > networks you don't trust.
>
> Yes, we're using 'password password' in our pg_hba.conf file. I trust my
> network (so far).
That is another major limitation to secondary password files. In fact,
md5
>
> Yes, is that your pg_hba.conf line? 'password' is insecure over
> networks you don't trust.
Yes, we're using 'password password' in our pg_hba.conf file. I trust my
network (so far).
-ron
---(end of broadcast)---
TIP 1: subscribe and unsub
Hi,
We had seen the following exception when we tried for a heavy query(around
1 to 2 in result is possible)
An I/O error occured while reading from backend - Exception:
java.net.SocketException: socket closed: Bad file number
Stack Trace:
java.net.SocketException: socket closed: Bad fi
Ron Snyder wrote:
> > OK, how do secondary passwords work in pg_hba.conf. It requires
> > clear-text 'password', right, because the password is already crypt-ed
> > in the file.
>
> I presume that you're referring to passwords being transmitted clear text?
Yes, is that your pg_hba.conf line?
> OK, how do secondary passwords work in pg_hba.conf. It requires
> clear-text 'password', right, because the password is already crypt-ed
> in the file.
I presume that you're referring to passwords being transmitted clear text?
> One idea I had was to look for a colon in the username, and if
Tom Lane writes:
> > Socket permissions - only install user can access db by default
>
> I do not agree with this goal.
It is my understanding that there is currently a lot of criticism that the
default setup is open to all local users. This is nearly the same as
having the data area files them
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Oleg Bartunov wrote:
> Bruce,
>
> please find
Ron Snyder wrote:
> > As for 7.3, maybe we can get that done in time of everyone
> > likes it. If
> > we can't, what do we do? Do we re-add the secondary password
> > file stuff
> > that most people don't like? My big question is how many other
> > PostgreSQL users figured out they could use
> As for 7.3, maybe we can get that done in time of everyone
> likes it. If
> we can't, what do we do? Do we re-add the secondary password
> file stuff
> that most people don't like? My big question is how many other
> PostgreSQL users figured out they could use the secondary
> password fil
On Tuesday 30 July 2002 00:23, Tom Lane wrote:
> Ian Barwick <[EMAIL PROTECTED]> writes:
> > - Does src/include/postgres_ext.h count as a parser definition file?
>
> No, it doesn't. Your experience sounds like you may have neglected to
> do a full rebuild after altering NAMEDATALEN. (By default,
Andrew Sullivan wrote:
> Actually, the comparison is apt. There's a reason people suggest
> using your distribution's PHP or Zope or what-have-you packages,
> rather than installing from source: an inexperienced user with these
> packages could easily spend several days trying to figure out all t
Tom Lane wrote:
> >> Another idea is to change pg_hba.conf to not default to 'trust' but then
> >> the installing user is going to have to choose a password.
>
> Well, initdb already has an option to request a password. It would
> perhaps make sense for initdb to alter the installed pg_hba.conf
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> > Socket permissions - only install user can access db by default
> >>
> >> I do not agree with this goal.
>
> > OK, this is TODO item:
>
> > * Make single-user local access permissions the default by limiting
> >
> > psql is very definitely not ready, nor is pgaccess.
I could not really trace who said this.
To my understanding nobody is currently testing how pgaccess is dealing
with 7.3 Am I wrong?
Most problems we try to address now are related to pgaccess working on
most platforms (Brett fights with
Added to open items list:
handle lack of secondary passwords
---
Marc G. Fournier wrote:
>
> add in 'fix pg_hba.conf / password issues' to that too :)
>
> On Tue, 30 Jul 2002, Bruce Momjian wrote:
>
> >
> > Here
Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Neil Conway wrote:
>
> > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote:
> > > add in 'fix pg_hba.conf / password issues' to that too :)
> >
> > I doubt that will make 7.3 -- the proposals I've seen on this topic
> > require some re
Neil Conway wrote:
> On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote:
> > NAMEDATALEN - disk/performance penalty for increase, 64, 128?
>
> In my personal testing, I've been unable to observe a significant
> performance impact (as Tom mentioned, I tried getting some profiling
> data
Thomas Lockhart wrote:
> ...
> > 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 g
Christopher Kings-Lynne wrote:
> > > 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...
Description updated:
Dependency - have pg_dump auto-create depende
Neil Conway wrote:
> On Wed, Jul 31, 2002 at 03:30:30PM -0400, Bruce Momjian wrote:
> > Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> > to prove we are not causing performance problems. Once that is done,
> > the default limits can be easily increased. I was thinking
If you can contribute it, I think it would be valuable to the two other
Win32 projects that are working on porting the 7.3 code to Win32.
I don't think they will have any code ready for 7.3 but they may have a
few pieces they want to get in to make their 7.3 patching job easier,
like renaming ma
Tom Lane wrote:
> > 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.
Yes, I listed it just to keep it on the radar.
> > Win32 - timefame?
>
> I've seen nothing to make me think
>> Another idea is to change pg_hba.conf to not default to 'trust' but then
>> the installing user is going to have to choose a password.
Well, initdb already has an option to request a password. It would
perhaps make sense for initdb to alter the installed pg_hba.conf file
to select local md5 m
> Another idea is to change pg_hba.conf to not default to 'trust' but then
> the installing user is going to have to choose a password.
I like this approach. Set it to password (or md5) on local, and force
the request of a password during initdb.
If for some reason they forget their password, t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> Socket permissions - only install user can access db by default
>>
>> I do not agree with this goal.
> OK, this is TODO item:
> * Make single-user local access permissions the default by limiting
> permissions on the socket file (P
On Wed, Jul 31, 2002 at 03:30:30PM -0400, Bruce Momjian wrote:
> Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> to prove we are not causing performance problems. Once that is done,
> the default limits can be easily increased. I was thinking 64 for
> NAMEDATALEN and 3
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> to prove we are not causing performance problems. Once that is done,
> the default limits can be easily increased. I was thinking 64 for
> NAMEDATALEN and 32 for FUNC_MAX_ARGS,
Tom Lane wrote:
> > 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% slo
Tom Lane wrote:
> > Socket permissions - only install user can access db by default
>
> I do not agree with this goal.
OK, this is TODO item:
* Make single-user local access permissions the default by limiting
permissions on the socket file (Peter E)
Right now, we effectively install initdb
> How many thousands of web sites out there don't offer PgSQL due to teh
> hassle? Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple
> 'libpq.tar.gz' that could be downloaded, nice and small, then we've just
> made enabling PgSQL by default in mod_php4 brain dead ...
Case in point
Andrew Sullivan wrote:
> Sorry, I think I wasn't making myself clear. I think that's a
> splendid idea. But I'm not sure it's worth paying for it by making
> users who want the whole thing download multiple packages. Maybe I'm
> alone in thinking that, however, and it's not like I feel terri
On Wed, Jul 31, 2002 at 03:11:40PM -0300, Marc G. Fournier wrote:
> hassle? Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple
> 'libpq.tar.gz' that could be downloaded, nice and small, then we've just
> made enabling PgSQL by default in mod_php4 brain dead ...
Sorry, I think I wa
On Wed, Jul 31, 2002 at 02:36:43PM -0300, Jeff MacDonald wrote:
>
> When you install freebsd or linux, is it a problem that all the
> perl modules you need have to fetched from cpan ? why can't they
> call just be part of the OS ?'
Well, not just part of the OS, but part of Perl. And after all,
On Wed, 31 Jul 2002, 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
Bruce,
please find attached patch to current CVS ( contrib/ltree )
Changes:
July 31, 2002
Now works on 64-bit platforms.
Added function lca - lowest common ancestor
Version for 7.2 is distributed as separate package -
http://www.sai.msu.su/~megera/postgres/gist/ltree/ltree-7.2.tar.g
> 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 anyon
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
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
Bruce Momjian writes:
> Thomas, are you going to extend this to locations for any table/index?
> Seems whatever we do for WAL should fix in that scheme.
The trick is that it might not. For relations you simply need a system
table mapping location names to file system locations, and you can add
On Wed, 31 Jul 2002, Neil Conway wrote:
> On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote:
> > add in 'fix pg_hba.conf / password issues' to that too :)
>
> I doubt that will make 7.3 -- the proposals I've seen on this topic
> require some reasonably complex additions to the auth
On Wed, 31 Jul 2002, Tom Lane wrote:
> [EMAIL PROTECTED] (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
> h
> > 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.
>
>
On Wed, 31 Jul 2002, Neil Conway wrote:
> 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 t
"John Liu" <[EMAIL PROTECTED]> writes:
> I tried to understand what causes
> too many pgsql idle processes. Can
> postmaster automatically aged and
> cleaning up those unused idle process?
Those processes are attached to open client connections. If you don't
like them, change your client to clo
> > Since I see a huge benefit in allowing conditional rules for a view,
> > I think it is worth finding a solution.
>
> We do allow conditional rules for a view. You just have to write an
> unconditional one too (which can be merely DO INSTEAD NOTHING).
Hmm, but you cannot then trow an error,
I tried to understand what causes
too many pgsql idle processes. Can
postmaster automatically aged and
cleaning up those unused idle process?
Is there a catalog to track those
psql processes - what their functions, who
issues, etc.?
thanks.
johnl
---(end of broadcast)
[EMAIL PROTECTED] (Neil Conway) writes:
>> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> Until someone takes the time to determine what the performance
> implications of this change will be, I don't think we should
> change this. Given that no one has done any testing, I'm not
On Wed, Jul 31, 2002 at 11:09:58AM -0400, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > Ok, how then would one set the location of the config file?
>
> The config file itself has to be found the same way we do it now,
> obviously: either a command line argument or the environm
On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote:
> add in 'fix pg_hba.conf / password issues' to that too :)
I doubt that will make 7.3 -- the proposals I've seen on this topic
require some reasonably complex additions to the authentication
system. We also still need to hash out
On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote:
> NAMEDATALEN - disk/performance penalty for increase, 64, 128?
In my personal testing, I've been unable to observe a significant
performance impact (as Tom mentioned, I tried getting some profiling
data with gprof + pgbench, and foun
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> Ok, how then would one set the location of the config file?
The config file itself has to be found the same way we do it now,
obviously: either a command line argument or the environment variable
$PGDATA. But that's a red herring. This thread is not
[EMAIL PROTECTED] (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 doi
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
> s
On Wed, Jul 31, 2002 at 10:23:07AM -0400, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > a. The system uses no environment variables at all; some other
> > method is used to determine where the config file is (maybe compiled
> > into the code);
>
> > If I understand it, nobody
1 - 100 of 111 matches
Mail list logo
