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 Datatshirts, merchandize
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
= '2-name2'
On 31 Jul 2002, Hannu Krosing wrote:
An it is often easier to map OO languages to OOR database when you dont
have to change your mindset when going through the interface.
But you have to anyway! Adding this inheritance does not remove the
relational model; it's still there right in front of
...
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
On Tue, 30 Jul 2002, Thomas Lockhart wrote:
The no envar camp has not thought through the issues yet, though the
issues can be found in the threads. Better to decide what the
requirements are before throwing out the solution.
Ok, so what issues has the no envvar camp not yet dealt with?
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2002-07-31 at 10:22, Tom Lane wrote:
Hm. How about
ERROR: Cannot insert into a view
You need an unconditional ON INSERT DO INSTEAD rule
Seems more accurate, but actually you may also have two or more
conditional rules that cover all
...
But ... my recollection is that we've had a *huge* number of complaints
about the initlocation behavior, at least by comparison to the number
of people using the feature. No one can understand how it works,
let alone how to configure it so that it works reliably. I really
fail to
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 patch uses a
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]
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, but
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 near
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
...
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
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 (path)
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 is really
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.
Actually not:
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 NOTHING).
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
[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
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 environment
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
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
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, but
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 close
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 anyone
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 of
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
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 terribly
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, I
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 that
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
have to
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
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 -
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 as
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% slowdown
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, we
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
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 32
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 (Peter E)
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,
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 mode
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 this
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
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
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 64
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 dependencies
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 with
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 reasonably
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 are the
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
permissions on
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
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 file
to
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
for
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 the
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
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 I
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?
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 will not
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 careful
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)---
TIP 1:
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 major limitation to
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 like
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 ... and
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
network (so far).
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 'password password' in our
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 trust.
Yes, we're
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? 'password' is insecure over
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 now
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 postmaster
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 compiled-in
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
connected
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 server,
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 actually
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
CREATE
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 thought of ...
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
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 the user
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
withouth.
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.
No,
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 I
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.
Please
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), but
I
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've
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), but
1 - 100 of 106 matches
Mail list logo
