Skip site navigation (1) Skip section navigation (2)

Re: Thoughts on pg_hba.conf rejection

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Thoughts on pg_hba.conf rejection
Date: 2010-04-21 04:14:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I suppose the problem here is that pg_attribute and pg_class are not
>> shared catalogs, so we can't read them without selecting a database.
> Among other things.
>> What about making a fake version of these relations that includes only
>> the shared catalogs?
> Well, after you solve the few dozen problems standing in the way
> of that, go right ahead.  I'm not holding up 9.0 for it though.
> (You might want to look back at the archived discussions about how to
> avoid storing entries for temp tables in these catalogs; that poses
> many of the same issues.)

Do you happen to know what a good search term might be?  I tried
searching for things like "pg_class temp tables" and "pg_class
temporary tables" and didn't come up with much.  The closest thing I
found was a discussion about global temp tables (subject aws "idea:
global temp tables") in which Greg Stark was arguing that there wasn't
much point in implementing them without solving this issue (and others
were disagreeing) but it didn't get into any of the technical issues
at all.


In response to


pgsql-hackers by date

Next:From: feng tianDate: 2010-04-21 05:03:10
Subject: libpq connectoin redirect
Previous:From: Robert HaasDate: 2010-04-21 03:46:06
Subject: Re: testing HS/SR - 1 vs 2 performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group