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 d
[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]
> >
[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
> 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 sp
[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
> > > ha
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
On Tue, 2002-07-30 at 16:49, Tom Lane wrote:
> 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
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 dom
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 dire
- 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 Or
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 the
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
> ... 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
> lea
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
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" <[EM
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 th
> 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, 2
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 cle
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 Russi
> 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 has offered to help integrate this into the main documentation set,
and he certainly understands how to work with those for patching etc.
There is no downside to havi
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 unregister
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 gr
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, va
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?
Mak
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 1-de
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_
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
-Origi
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 l
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
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 behaviou
> > 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?
> > >
>
> 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 s
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 :)
> C
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
* 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 star
* 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 distinguishes us.
>
> Col. Let's have the 'automatically phone KFC if dev
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
> 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 com
> > 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
"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
> impleme
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:
uvsca
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 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. An
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 rig
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
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
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
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 clean
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 d
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 imple
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 standar
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
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
> thro
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 previou
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 alm
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 e
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, t
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 a
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 Jul
> 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.
> Postg
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)
> wh
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 func
On Tuesday 30 July 2002 02:34 pm, Tom Lane wrote:
> 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
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? T
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 ca
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 t
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 recog
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
Thomas Lockhart writes:
> 31) Specifications for Feature F511, "BIT data type":
> a) Subclause 5.3, "":
>i) Without Feature F511, "BIT data type", a
> shall not be a or a literal>.
>
> This seems to be a hard linkage of hex strings with the BIT type.
You'll also find in 5.3 Con
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.
> >
>
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 pers
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 insecu
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 w
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
...
> 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
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 i
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 ve
...
> 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, the
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 th
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
--
1 - 100 of 156 matches
Mail list logo
