On Tue, 2007-05-06 at 14:50 +0530, NikhilS wrote:
> PFA, a patch which provides the "CREATE .. INCLUDING INDEXES"
> functionality. This patch uses the same functionality introduced by
> the earlier patches in this thread albeit for the "INCLUDING INDEXES"
> case.
Attached is a revised version of
[ back to the cluster-order patch ]
Awhile back, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> The performance characteristics of this patch hasn't been thoroughly
> discussed yet. The reason why you want to cluster your tables is to
> speed up SELECTs that return a bunch of tuples with simila
On Mon, Jul 09, 2007 at 06:13:54PM +0100, Gregory Stark wrote:
> I'm not suggesting making dblink super-user only. Only revoking public execute
> bits in the default install script. That doesn't affect users upgrading so I
> don't see a backwards-compatibility issue.
>
> The doc changes are going
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > But if you know of a security risk related to using libpq
> > with a password authenticated connection, let's hear it.
>
> As near as I can tell, the argument is that dblink might be used to send
> connection-reque
"Tom Lane" <[EMAIL PROTECTED]> writes:
> So I guess the scenario is that you're running your database on your
> firewall machine, where it is accessible from outside your net but also can
> reach addresses inside.
Well typically the database is behind the firewall but an application is
outside th
Joe Conway <[EMAIL PROTECTED]> writes:
> But if you know of a security risk related to using libpq
> with a password authenticated connection, let's hear it.
As near as I can tell, the argument is that dblink might be used to send
connection-request packets to random addresses. Now this is only
Gregory Stark wrote:
"Joe Conway" <[EMAIL PROTECTED]> writes:
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
There are none installed by default -- that's the point.
Uhh... None what? Functions in untrusted languages? That's certainly
not the case, there's a whole slew of th
Stephen Frost wrote:
It's about as good as saying "Well, an admin had to install PostgreSQL
on the system, by choice, and therefore we don't need to worry about PG
allowing someone remote shell access to the system".
That's a ridiculous assertion -- I said nothing of the sort.
Joe
---
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Get serious. Internal functions are specifically designed and maintained to
> be safe within the confines of the database security model. We are
> discussing extensions to the core, all of which must be installed by
> choice, by a superuser.
Extensions
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Stephen Frost wrote:
>> * Joe Conway ([EMAIL PROTECTED]) wrote:
>>> There are none installed by default -- that's the point.
>>
>> Uhh... None what? Functions in untrusted languages? That's certainly
>> not the case, there's a whole slew of them, from
Jaime Casanova wrote:
what makes me wonder why doesn't exist "pg_ctl init"
I suggested it in previous discussion on hackers. See
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00142.php
Zdenek
---(end of broadcast)--
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Dave Page wrote:
This is almost as bad as Magnus agreeing with JD (!), but I agree with
Peter :-). After years of typing the current names, changing them does
seem somewhat annoying. Worse yet, pg_* is just awkward to type.
But these u
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
There is group of people who has different opinion. The main reasons for
this patch are 1) names could collide with system tools
That argument is purely theoretical, though, since no one has complained
to us of an *actual* collision. W
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
There are none installed by default -- that's the point.
Uhh... None what? Functions in untrusted languages? That's certainly
not the case, there's a whole slew of them, from boolin to
generate_series and beyond. They're availabl
14 matches
Mail list logo
