Tom mentioned that he had not had these security concerns raised before. From
my point of view I just have no idea about the level of information offered
to any given user and am scared to run PostgreSQL in an ISP shared
environment because of it. I am sure I can secure people from connecting
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> >It bothers me a great deal that I can't control very easily what a given
> >user can see when they connect over ODBC or via phppgadmin in terms of
> >schemas, tables and columns. I fixed this in application code in
> >phppgadmin but that's cl
On Sat, May 14, 2005 at 08:55:17AM -0400, Stephen Frost wrote:
> * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > >It bothers me a great deal that I can't control very easily what a given
> > >user can see when they connect over ODBC or via phppgadmin in terms of
> > >schemas, tables and co
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
> On Sat, May 14, 2005 at 08:55:17AM -0400, Stephen Frost wrote:
> > * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > > Hackers - we get an email about information hiding in shared
> > > postgresql/phppgadmin installations at least once a fortnight
On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Another thought I had along that line was use a different signal to
> > simply do a "query cancel" and set a global flag that is more or less
> > "get out when you're done with query cancel
On Sat, May 14, 2005 at 10:00:09AM -0400, Stephen Frost wrote:
> * Jim C. Nasby ([EMAIL PROTECTED]) wrote:
> > On Sat, May 14, 2005 at 08:55:17AM -0400, Stephen Frost wrote:
> > > * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > > > Hackers - we get an email about information hiding in shar
Jim C. Nasby wrote:
On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
Another thought I had along that line was use a different signal to
simply do a "query cancel" and set a global flag that is more or less
"get out when you're done wi
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Another thought I had along that line was use a different signal to
> > simply do a "query cancel" and set a global flag that is more or less
> > "get out when you're done with query cancel". Then if that flag is set,
> > just clos
Bruce Momjian writes:
> Can't we
> have a signal that does a query cancel, does the normal cancel cleanup,
> then exits rather than asking for another query?
That *is* what we have.
I give up trying to explain myself, since it's obvious that I'm not
getting through to anyone. Commit the darn th
Tom Lane wrote:
> "Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> > If I have on-disk bitmap
> > ON (a, b, c)
> > will the planner pick an index scan for
> > WHERE a = 42 AND b = 'foo'
> > (i.e. only part of the index attributes are involved)? Any modifications
> > needed to achieve this
I meant to mention this during previous discussion.
Currently the pg_regress script does "dbname=regression" and then does
everything in terms of $dbname. Would there be any value in providing a
--dbname=foo parameter so that different regression sets could use their
own db? One virtue at least
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Currently the pg_regress script does "dbname=regression" and then does
> everything in terms of $dbname. Would there be any value in providing a
> --dbname=foo parameter so that different regression sets could use their
> own db? One virtue at least
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Currently the pg_regress script does "dbname=regression" and then does
everything in terms of $dbname. Would there be any value in providing a
--dbname=foo parameter so that different regression sets could use their
own db? One virt
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The easy implementation would require building a temp install tree for
>> each PL, which seems mighty slow and disk-space-hungry.
> yes, way too much work if done as a separate run. The only way it would
> make sense to me would be i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Try attached ... season to taste. The bulk of it is changes for dblink
> which has the dbname hardcoded.
Joe, any objections here?
regards, tom lane
---(end of broadcast)---
TIP
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Try attached ... season to taste. The bulk of it is changes for dblink
which has the dbname hardcoded.
Joe, any objections here?
Haven't been able to keep up with the lists at all for the past few
days, but I'll take a look later today.
16 matches
Mail list logo
