On Mon, 2002-07-29 at 18:30, Bruce Momjian wrote:
Curt Sampson wrote:
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a couple of times here, and nobody has even started
to come up with anything.
We inherited inheritance from Berkeley. I doubt we
[don't cc: me, please.]
[please leave proper attribution in]
On Tue, 2002-07-30 at 10:45, Christopher Kings-Lynne wrote:
We inherited inheritance from Berkeley. I doubt we would have added it
ourselves. It causes too much complexity in other parts of the system.
[Inheritance]
How
[No cc: please. Especially if you're not commenting on anything I said]
On Tue, 2002-07-30 at 13:46, D'Arcy J.M. Cain wrote:
Curt Sampson wrote:
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a couple of times here, and nobody has even started
As an implementor I'm always wary of using features nobody else has,
especially in databases. So, if I'd want postgres to have one thing
nobody else has, it would be the most complete standard SQL
implementation - so it would at least be the other products' fault if
I'd have to do any
[Still no cc:s please]
On Tue, 2002-07-30 at 14:28, D'Arcy J.M. Cain wrote:
* Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [020730 08:01]:
On Tue, 2002-07-30 at 13:46, D'Arcy J.M. Cain wrote:
I think one of the values of it is that it is something that no one else
has. It
Adrian 'Dagurashibanipal' von Bidder wrote:
(And that's where I'm starting to say things I've said before. So I'll
just shut up now.)
May be you can contribute some code :)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Tue, 30 Jul 2002, Andrew Sullivan wrote:
On Tue, Jul 30, 2002 at 12:43:52AM -0300, Marc G. Fournier wrote:
since as soon as there are two 'bruce' users, only one can have a password
I guess I don't understand why that's a problem. I mean, if you're
authenticating users, how can you
Marc G. Fournier wrote:
I think that is the problem with everyone's thinking ... they are only
dealing with 'small servers', where it only has a couple of databases ...
I'm currently running a server with 100 domains on it, each one with *at
least* one database ... each one of those domains,
On Tue, Jul 30, 2002 at 08:10:02PM +0900, Curt Sampson wrote:
BTW, you mention in another message that environment variables work
well for you. Well, they are a security problem waiting to happen,
IMHO. Do you have any objections to having a file containing a list
of the various data
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED]; [EMAIL PROTECTED]
We would have to understand how the SGI code is better than our existing
code on SMP machines.
I've been searching for data from SGI's Origin
I have implemented the ROW keyword, but am not sure that I've gotten
what the spec intends to be the full scope of functionality. It may be
that I've missed the main point completely :)
If someone has the time and interest I'd appreciate it if they would go
through the SQL99 spec and see what
On Tue, Jul 30, 2002 at 02:05:57PM -0400, Tom Lane wrote:
If we add more environment-variable-dependent mechanisms to allow more
different things to be done, we increase substantially the odds of
creating an exploitable security hole.
Ok, true enough, but I'm not sure that a config file or
... amongst all the various 'bruce's...
Hmm. The Monty Python scenario? :)
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
On Tue, Jul 30, 2002 at 11:55:55AM -0300, Marc G. Fournier wrote:
I think that is the problem with everyone's thinking ... they are only
dealing with 'small servers', where it only has a couple of databases ...
I'm currently running a server with 100 domains on it, each one with *at
least*
On Tue, Jul 30, 2002 at 04:21:24PM -0400, Tom Lane wrote:
However, the real question is what is the use-case for this feature
anyway. Why should people want to reset the stats while the system
is running? If we had a clear example then it might be more apparent
what restrictions to place on
I wonder if we should just point to Oleg's URL from our docs. That way,
as he adds stuff, people can go there to get it.
---
Oleg Bartunov wrote:
On Tue, 30 Jul 2002, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL
On Tue, 2002-07-30 at 16:55, Marc G. Fournier wrote:
On Tue, 30 Jul 2002, Andrew Sullivan wrote:
On Tue, Jul 30, 2002 at 12:43:52AM -0300, Marc G. Fournier wrote:
since as soon as there are two 'bruce' users, only one can have a password
I guess I don't understand why that's a
2. I expect that even most PostgreSQL--or even database--experts don't
have a real understanding of relational theory, anyway. That we still
have table inheritance shows that. As far as I can tell, there is
nothing whatsoever that table inheritance does that the relational model
does not
Adrian 'Dagurashibanipal' von Bidder wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
[Still no cc:s please]
On Tue, 2002-07-30 at 14:28, D'Arcy J.M. Cain wrote:
* Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [020730 08:01]:
On Tue, 2002-07-30
I've got patches to adjust the interpretation of hex literals from an
integer type (which is how I implemented it years ago to support the
*syntax*) to a bit string type. I've mentioned this in a previous
thread, and am following up now.
One point raised previously is that the spec may not be
On Tue, 30 Jul 2002, Bruce Momjian wrote:
I wonder if we should just point to Oleg's URL from our docs. That way,
as he adds stuff, people can go there to get it.
I think better to have basic GiST documentation shipped and a point
to our page. We have complete GiST API documented in Russian
Oh, I've also implemented int8 to/from bit conversions, which was a
trivial addition/modification to the int4 support already there...
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
What's with this manual page?
http://candle.pha.pa.us/main/writings/pgsql/sgml/gist.html
GiST is, um, *very* poorly documented. Feel free to submit doc patches.
(I've just committed a few tidbits in xindex.sgml, but much more work
is needed.)
Weell...first I'd have to learn GiST...
Hi All,
This is another cut of the DROP COLUMN patch. I have split the drop
function into two parts - and now handle dependencies.
Problems:
1. It cascade deletes objects, but it _always_ cascades, no matter what
behaviour I specify. Also, it doesn't give me indications that it's cascade
On Tue, 30 Jul 2002, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What's with this manual page?
http://candle.pha.pa.us/main/writings/pgsql/sgml/gist.html
GiST is, um, *very* poorly documented. Feel free to submit doc patches.
(I've just committed a few tidbits in
On Tue, 30 Jul 2002, Jeff Davis wrote:
Can you point me (someone without a real understanding of relational theory)
to some good resources that explain the concepts well?
C. J. Date's _An Introduction to Database Systems, Seventh Edition_ is
a fat tome that will give you an extremely good
I'm having a weird problem on my PostgreSQL 7.2.1 on i386--netbsdelf,
compiled by GCC 2.95.3 system. Executing these commands:
CREATE TABLE test_one (id int PRIMARY KEY, value_one text);
CREATE TABLE test_two (id int PRIMARY KEY, value_two text);
CREATE VIEW test AS
SELECT test_one.id,
Curt Sampson [EMAIL PROTECTED] writes:
CREATE VIEW test AS ...
CREATE RULE test_insert AS
ON INSERT TO test
DO ...
INSERT INTO test VALUES (1, 'one', 'onemore');
ERROR: Cannot insert into a view without an appropriate rule
What am I doing wrong here? Is there a bug?
Make that
Hi,
I see different results in Oracle and postgres for same outer join queries.
Here are the details.
I have the following tables in our pg db
table: yuva_test1
yt1_id yt1_nameyt1_descr
1 1-name1 1-desc1
2 1-name2 1-desc2
3 1-name3
Yuva Chandolu [EMAIL PROTECTED] writes:
I see different results in Oracle and postgres for same outer join queries.
I believe you are sending your bug report to the wrong database.
When I run the query select yt1_name, yt1_descr, yt2_name, yt2_descr from
yuva_test1 left outer join yuva_test2
Hi Tom,
Thanks for your prompt reply, after second thought(before receiving your
reply) I realized that postgres is doing more logically - i.e if the outer
join condition returns false then replace by nulls for right table columns.
We may change our code accordingly :-(.
Thanks
Yuva
On Tue, 30 Jul 2002, Yuva Chandolu wrote:
Hi,
I see different results in Oracle and postgres for same outer join queries.
Here are the details.
Those probably aren't the same outer join queries.
When I run the query select yt1_name, yt1_descr, yt2_name, yt2_descr from
yuva_test1 left
On Tue, 30 Jul 2002, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
CREATE VIEW test AS ...
CREATE RULE test_insert AS
ON INSERT TO test
DO ...
INSERT INTO test VALUES (1, 'one', 'onemore');
ERROR: Cannot insert into a view without an appropriate rule
What am I
Curt Sampson [EMAIL PROTECTED] writes:
ERROR: Cannot insert into a view without an appropriate rule
Perhaps the error message could be phrased better --- any thoughts?
Maybe a message that says something along the lines of cannot insert
into views; you need to override this behaviour with
We inherited inheritance from Berkeley. I doubt we would have added it
ourselves. It causes too much complexity in other parts of the system.
How about dropping it, then?
Just start to emit
WARNING: inheritance will be dropped with postgres 8.0
WARNING: please refer to http://.../
On Tue, 2002-07-30 at 10:40, Marc G. Fournier wrote:
On Tue, 30 Jul 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
You seem to have done a nice job with the + and for 'maps' ... how about
third on that states that the map file has a username:password pair in it?
I do like
We would have to understand how the SGI code is better than our existing
code on SMP machines.
there is a big problem with postgres on SGI NUMA architectures, on UMA
systems postgres works fine, but NUMA Origins need a native shared memory
management. It scales fine over old challenges, but
On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote:
Bruce Momjian:
It causes too much complexity in other parts of the system.
That's one reason.
Seems like somewhat valid reason. But still not enough to do a lot of
work _and_ annoy a lot of existing users :)
Curt
On Wed, 31 Jul 2002, Tom Lane wrote:
Well, to my mind that's what the error message says now. The reason
it didn't help you was that you *did* have a rule ... but it didn't
completely override the view insertion.
Right, like I said, my model was wrong. I didn't think of the error
message as
* Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [020730 04:20]:
On Mon, 2002-07-29 at 18:30, Bruce Momjian wrote:
Curt Sampson wrote:
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a couple of times here, and nobody has even started
to
Curt Sampson [EMAIL PROTECTED] writes:
On Wed, 31 Jul 2002, Tom Lane wrote:
Well, to my mind that's what the error message says now. The reason
it didn't help you was that you *did* have a rule ... but it didn't
completely override the view insertion.
Right, like I said, my model was
We have some docs...
it's written in Russian.
I could try to translate if needed.
That would be great! Perhaps someone would help to go through and edit
it after you do a first cut, so you don't need to spend time working on
exact phrasing but rather on the content itself. I admire your
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a couple of times here, and nobody has even started
to come up with anything.
and
there is nothing whatsoever that table inheritance does that the
relational model does not handle
That's the other
Luis Alberto Amigo Navarro [EMAIL PROTECTED] writes:
if you want postgres to run fine on this machines I think (it's not tested
yet) it would be neccesary to implement native shared arenas instead of IPC
shared memory in order to let IRIX make a fine load-balance.
In CVS tip, the direct
On Tue, Jul 30, 2002 at 02:01:35PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote:
As an implementor I'm always wary of using features nobody else has,
especially in databases. So, if I'd want postgres to have one thing
nobody else has, it would be the most complete standard SQL
On Wed, 31 Jul 2002, Tom Lane wrote:
ERROR: Cannot insert into a view
You need an unconditional ON INSERT DO INSTEAD rule
Sounds great to me!
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light.
... But I strongly feel that having a feature
because 'it is something that no one else has. It distinguishes us.' is
no justification at all.
One reason why we have a database which *does* come very close to the
standards is precisely because it had (and has) things which no one else
had
Okay, am playing with this on one of my 'none-critical' servers right now
... tried to use uvscan from teh command line, and it didn't appear to
pick up any of the Klez stuff, even though I know I have a few in my
mailbox ...
What options should I be running as? I'm using the following:
Hannu Krosing [EMAIL PROTECTED] writes:
I am trying to create an aggregate function that works on whole tuples,
but the system does not find them once defined ;(
hannu=# select tabulate(users) from users;
ERROR: No such attribute or function 'tabulate'
This seems to work in CVS tip. I
Marc G. Fournier wrote:
so, I can easily do something like:
host database bruce IP1
host database bruce IP2
and know that client on IP1 can't look at client on IP2s database, even
with the same user ... but in a VH environment, you have:
host database bruce IP1
host database bruce
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I have one idea. Right now the file format for usernames can be:
But this is just reimplementing the original functionality, which was
quite broken IMHO. The setup Marc is describing doesn't really have
users per-database, it's only faking it. And
figured it out ... uvscan isn't looking where ports installed the newer
.dat files ... fixed that and it finds 63 virii infected files instead of
just 5 :)
one step closer ...
On Tue, 30 Jul 2002, Marc G. Fournier wrote:
Okay, am playing with this on one of my 'none-critical' servers right
On 29 Jul 2002, Hannu Krosing wrote:
Curt Sampson wrote:
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a couple of times here, and nobody has even started
to come up with anything.
It is mostly a syntactic thing that makes it easier to
On 30 Jul 2002, Hannu Krosing wrote:
On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote:
Bruce Momjian:
It causes too much complexity in other parts of the system.
That's one reason.
Seems like somewhat valid reason. But still not enough to do a lot of
work
On Mon, 29 Jul 2002, Thomas Lockhart wrote:
It is supported by the installation environment, and does not require
the explicit three steps of
1) creating a new directory area
2) moving files to the new area
3) creating a symlink to point to the new area
So basically it gives you the
Tom Lane writes:
(5) is not really needed if we
take pg_dump's current approach of associating a language with the
namespace of the underlying function.
Well, do you like that? It was only a quick hack to get pg_dump
running with schemas; I'm not convinced we really want it to act
Tom Lane writes:
As an alternative syntax I can suggest
SET name TO value [ ON COMMIT RESET ];
Ugh. Why can't we stick with SET LOCAL?
SET LOCAL is already used for something else in the SQL standard. Not
sure if we'll ever implement that, but it's something to be concerned
about.
--
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Well, do you like that? It was only a quick hack to get pg_dump
running with schemas; I'm not convinced we really want it to act
that way.
We should probably put the languages into a schema.
Well, that would be the cleanest
Patch applied. Thanks.
---
Oleg Bartunov wrote:
On Sun, 21 Jul 2002, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
We are about to submit brand bew contrib/ltree module
(first draft of documetation
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
As an alternative syntax I can suggest
SET name TO value [ ON COMMIT RESET ];
Ugh. Why can't we stick with SET LOCAL?
SET LOCAL is already used for something else in the SQL standard. Not
sure if we'll ever implement that,
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
As an alternative syntax I can suggest
SET name TO value [ ON COMMIT RESET ];
Ugh. Why can't we stick with SET LOCAL?
SET LOCAL is already used for something else in the SQL standard. Not
sure if
Andrew Sullivan wrote:
On Tue, Jul 30, 2002 at 08:10:02PM +0900, Curt Sampson wrote:
BTW, you mention in another message that environment variables work
well for you. Well, they are a security problem waiting to happen,
IMHO. Do you have any objections to having a file containing a list
Thomas Lockhart wrote:
I have implemented the ROW keyword, but am not sure that I've gotten
what the spec intends to be the full scope of functionality. It may be
that I've missed the main point completely :)
If someone has the time and interest I'd appreciate it if they would go
through
On Tuesday 30 July 2002 07:10 am, Curt Sampson wrote:
BTW, you mention in another message that environment variables work
well for you. Well, they are a security problem waiting to happen,
IMHO. Do you have any objections to having a file containing a list
of the various data directories?
Thomas Lockhart wrote:
I've got patches to adjust the interpretation of hex literals from an
integer type (which is how I implemented it years ago to support the
*syntax*) to a bit string type. I've mentioned this in a previous
thread, and am following up now.
One point raised previously
Andrew Sullivan [EMAIL PROTECTED] writes:
I guess I'm dumb, but I'm not seeing how these environment variables
are a big security risk.
The trouble with relying on environment variables for paths (especially
paths to places that we might scribble on) is that the postmaster has
no idea which
Okay, this is sweet ... but can someone tell me where I 'Buy' a copy of
uvscan? I've searched McAfee, but can't seem to find it in their eStore
anywhere ...
On 28 Jul 2002, Larry Rosenman wrote:
On Sun, 2002-07-28 at 20:10, Marc G. Fournier wrote:
God, I go through 200+ of those almost
Try their corporate sales droids
If you can't find one, I'll ask my contract client
LER
On Tue, 2002-07-30 at 13:20, Marc G. Fournier wrote:
Okay, this is sweet ... but can someone tell me where I 'Buy' a copy of
uvscan? I've searched McAfee, but can't seem to find it in their
Andrew Sullivan [EMAIL PROTECTED] writes:
On Tue, Jul 30, 2002 at 02:05:57PM -0400, Tom Lane wrote:
If we add more environment-variable-dependent mechanisms to allow more
different things to be done, we increase substantially the odds of
creating an exploitable security hole.
Ok, true
In my logic, we have PGDATA environment variable for the server only so
the server can find the /data directory. After that, everything should
be in /data. I see no reason to make it an environment variable.
In fact, a file in /data should be able to track the xlog directory a
lot better than
Oleg Bartunov wrote:
One known issue: It'll not works with 64-bit OS. We'll certainly fix this
but will appreciate if somebody with access to 64-bit machine could help us.
Actually, it dumps core instantly on 32-bit machines too, if they are
pickier about alignment than Intel hardware is.
I'm now working on it.
Tom Lane wrote:
Oleg Bartunov wrote:
One known issue: It'll not works with 64-bit OS. We'll certainly fix this
but will appreciate if somebody with access to 64-bit machine could help us.
Actually, it dumps core instantly on 32-bit machines too, if they are
pickier
Try here:
http://osdb.sourceforge.net/
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Ramsey
Sent: Tuesday, 30 July 2002 4:36 AM
To: [EMAIL PROTECTED]
Subject: [HACKERS] TPC-* Benchmarks
Have any organizations run TPC
Ah yes - that was me making an unfortunate exptrapolation without thinking
it through.
Of course, PHP implements persistent connections for you, etc., etc., not
the postgres client library.
Chris
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 30 July
As for why PostgreSQL is less popular than MySQL, I think it is all
momentum from 1996 when MySQL worked and we sometimes crashed. Looking
forward, I don't know many people who choose MySQL _if_ they consider
both PostgreSQL and MySQL, so the discussions people have over MySQL vs.
Christopher Kings-Lynne wrote:
OK, now I run it and it does absolutely nothing to the pg_stat_all_tables
relation for instance. In fact, it seems to do nothing at all - does the
reset function even work?
OK, I'm an idiot, I was calling the funciton like this: void blah(void)
which
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 function
Tom Lane wrote:
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
Lamar Owen [EMAIL PROTECTED] writes:
Having said all that, I still believe that this is something tailor-made for
postgresql.conf.
Well, exactly. Regardless of how serious you may think the security
argument is, it still remains that a config-file entry seems the ideal
way to do it. I can't
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Having said all that, I still believe that this is something tailor-made for
postgresql.conf.
Well, exactly. Regardless of how serious you may think the security
argument is, it still remains that a config-file entry seems the ideal
Bruce Momjian [EMAIL PROTECTED] writes:
A function seems like the wrong way to go on this. SET has super-user
protections we could use to control this but I am not sure what SET
syntax to use.
I don't like SET for it --- SET is for setting state that will persist
over some period of time,
Thomas Lockhart writes:
I've developed patches to be able to specify the location of the WAL
directory, with the default location being where it is now. The patches
define a new environment variable PGXLOG (a la PGDATA) and postmaster,
postgres, initdb and pg_ctl have been taught to
Neil Conway writes:
However, it would be useful to be able to do something like this -- how
about something like the following:
- the auth system contains a list of 'auth domains' -- an identifier
similar to a schema name
- the combination of (domain, username) must be
Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
As an alternative syntax I can suggest
SET name TO value [ ON COMMIT RESET ];
Ugh. Why can't we stick with SET LOCAL?
On Tue, 2002-07-30 at 16:00, Curt Sampson wrote:
On 30 Jul 2002, Hannu Krosing wrote:
On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote:
Bruce Momjian:
It causes too much complexity in other parts of the system.
That's one reason.
Seems like somewhat
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
A function seems like the wrong way to go on this. SET has super-user
protections we could use to control this but I am not sure what SET
syntax to use.
I don't like SET for it --- SET is for setting state that will persist
over
Thomas Lockhart [EMAIL PROTECTED] writes:
If we add more environment-variable-dependent mechanisms to allow more
different things to be done, we increase substantially the odds of
creating an exploitable security hole.
No. See above.
Your argument seems to reduce to it's not insecure
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't like SET for it --- SET is for setting state that will persist
over some period of time, not for taking one-shot actions. We could
perhaps use a function that checks that it's been called by the
superuser.
Should we have
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't like SET for it --- SET is for setting state that will persist
over some period of time, not for taking one-shot actions. We could
perhaps use a function that checks that it's been called by the
superuser.
...
Thomas, are you going to extend this to locations for any table/index?
Seems whatever we do for WAL should fix in that scheme.
Yes, the longer-term goal is enabling table/index-specific locations.
I'm not certain whether WAL can use *exactly* the same mechanism, since
1) the location for
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
1. It cascade deletes objects, but it _always_ cascades, no matter what
behaviour I specify. Also, it doesn't give me indications that it's cascade
deleted an object.
Would you give a specific example?
+ drop table child;
+ ERROR:
On Tue, 30 Jul 2002, Lamar Owen wrote:
Now, let me make the statement that the environment in this case is
not likely to be a security issue any worse than having the stuff
in postgresql.conf, as any attacker that can poison the postmaster
environment can probably poison postgresql.conf.
I have implemented the ROW keyword, but am not sure that I've gotten
what the spec intends to be the full scope of functionality. It may be
that I've missed the main point completely :)
...
afaict the spec is not at all verbose about this, and is very dense and
obtuse where it does
On 31 Jul 2002, Hannu Krosing wrote:
I would not rush to drop advanced features, as they may be hard to put
back later.
If they are hard to put back, it's generally because the other code
in the system that relates to it has changed, so you can't just bring
back what is in the old versions in
On Tue, 30 Jul 2002, Lamar Owen wrote:
On Tuesday 30 July 2002 02:34 pm, Tom Lane wrote:
Who said anything about poisoning the environment? My point was that
there will be strings in the environment that were put there perfectly
legitimately, but could still serve as an attack vehicle.
...
I've been securing systems since I started an ISP in 1995, and so I've
seen a lot of security vulnerabilities come and go, and I've got a bit
of a feel for what kinds of things are typically exploited. And this one
one just screams, potential security vulnerability! to me.
Sure, there is
On Tue, 30 Jul 2002, Thomas Lockhart wrote:
But the zeroth-order issue is not security. It is storage management for
large databases. Any scheme we have for accomplishing that must hold up
to scrutiny, but we can not refuse to proceed just because there are
lions tigers and bears out there.
I have implemented this TODO item:
* Add getpid() function to backend
There were a large number of pg_stat functions that access pids and
backends slots so I added it there:
test= select pg_stat_get_backend_mypid();
pg_stat_get_backend_mypid
On Mon, 2002-07-29 at 08:53, [EMAIL PROTECTED] wrote:
Just a long standing curiosity?
e) Inertia. MySQL got more popular way back when; the reasons may no longer
f) Win32 Support. I can download a setup.exe for mysql and have it up
and running quickly on Windows. I think that native Win32
On Tue, Jul 30, 2002 at 08:40:13PM -0400, Bruce Momjian wrote:
I have implemented this TODO item:
* Add getpid() function to backend
There were a large number of pg_stat functions that access pids and
backends slots so I added it there:
test= select
1 - 100 of 144 matches
Mail list logo
