> > Here are the details.
>
> Those probably aren't the same outer join queries.
I think you're right, these aren't the same, see below:
>
> > When I run the query "select yt1_name, yt1_descr, yt2_name, yt2_descr
> > from yuva_test1 left outer join yuva_test2 on yt1_id=yt2_id and yt2_name
> > =
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> It all works now and I have just submitted it to -patches as a
> new contrib,
> >> but it probably should make its way into the backend one day.
>
> > OK, the big question is how do we want to make stats reset visible to
> > users? The current patc
On Wed, 31 Jul 2002, Christopher Kings-Lynne wrote:
> I would also like to know this! They don't mention it anywhere on their
> site!
The FreeBSD command line version comes on the CD along with the windoze
versions.
>
> Chris
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [m
On Wed, Jul 31, 2002 at 02:00:52AM -0400, Tom Lane wrote:
> let alone how to configure it so that it works reliably. I really
> fail to understand why you want to drive this new feature off environment
> variables. You say you've "pointed out the utility and desirability"
> of doing it that way,
wow=# update \d dmoz
Table "dmoz"
Column | Type | Modifiers
+-+---
id | integer |
name | text|
path | ltree |
Indexes: dmoz_id_idx unique btree (id),
dmoz_path_idx gist ("path")
wow-#
wow-# ;
ERROR: parser: parse error at or ne
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
---(end of broadcast)---
TIP 5: Have you checked our exten
...
> Is this a fair account?
Yes. You may note that we have not explored the implementation details
on any of these, so the attributes of each are not cast in stone (except
for the purposes of argument of course ;)
- Thomas
---(end of broadcast)-
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 is really arguing for (a).
I am. I see absolutely no advantage in
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> wow=# update \d dmoz
> Table "dmoz"
> Column | Type | Modifiers
> +-+---
> id | integer |
> name | text|
> path | ltree |
> Indexes: dmoz_id_idx unique btree (id),
> dmoz_path_idx gist
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
> > Seems more accurate, but actually you may also have two or more
> > conditional rules that cover all possibilities if taken together.
> > Maybe
> > ERROR: Cannot insert into a view
> > You need an ON INSERT DO INSTEAD rule that matches your INSERT
> > Which covers both cases.
>
> Ac
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> 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 NOTHI
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
[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
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
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
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)
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
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
[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
> > 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,
"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
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
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
> 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
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
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, 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
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
> 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
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
> > 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, 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
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
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
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
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
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
> > 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
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,
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
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,
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:
> 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
> 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
>> 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
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
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
> 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
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
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
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
> 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
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?
>
> 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
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
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
> 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
> 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
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
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:
> 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
> 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
> > 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
>
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
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
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 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 '
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
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
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?
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
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
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
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
> >
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, 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
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
> >
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
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
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
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
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:
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
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, 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.
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 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.
>
1 - 100 of 111 matches
Mail list logo
