Jim Nasby writes:
> On 2/5/15 10:48 AM, Tom Lane wrote:
>> The dblink example is entirely uncompelling, given that as you said
>> somebody with access to a dblink connection could execute ALTER USER on
>> the far end.
> Actually, you can eliminate that by not granting direct access to dblink
> f
On 2/5/15 10:48 AM, Tom Lane wrote:
Stephen Frost writes:
>* Robert Haas (robertmh...@gmail.com) wrote:
>>On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost wrote:
>>>And I thought this was about FDW options and not about dblink, really..
>>The OP is pretty clearly asking about dblink.
>I was
On 2/5/15 10:13 AM, Tom Lane wrote:
> Robert Haas writes:
>> All that having been said, it wouldn't be crazy to try to invent a
>> system to lock this down, but it *would* be complicated. An
>> individual FDW can call its authentication-related options anything it
>> likes; they do not need to be
It is far from central to this conversation, but I can confirm that
RedShift currently only supports user+pass combinations.
It's likely that each node has a pg_hba.conf, but the customer is not given
credentials to ssh to the individual nodes.
On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost wrot
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Whether this is a realistic expectation given the wording of the SQL-MED
> standard is unclear.
I've only got a draft as of 2011-12 handy, but I'm not seeing anything
in the standard that cares one bit about the value of the options
specified for the FDW.
Tom Lane-2 wrote
> Stephen Frost <
> sfrost@
> > writes:
>> * Robert Haas (
> robertmhaas@
> ) wrote:
>>> On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost <
> sfrost@
> > wrote:
And I thought this was about FDW options and not about dblink, really..
>
>>> The OP is pretty clearly asking a
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost wrote:
>>> And I thought this was about FDW options and not about dblink, really..
>> The OP is pretty clearly asking about dblink.
> I was just pointing out that it was an iss
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost wrote:
> >> If she's got dblink access, she can run arbitrary
> >> SQL queries on the remote server anyway, which is all the password
> >> would let her do. Also, she could use dblink to run ALTER ROLE f
On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost wrote:
>> If she's got dblink access, she can run arbitrary
>> SQL queries on the remote server anyway, which is all the password
>> would let her do. Also, she could use dblink to run ALTER ROLE foo
>> PASSWORD '...' on the remote server, and then s
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 3, 2015 at 6:26 PM, Noah Yetter wrote:
> > The obvious objection is, "well you should just use foreign tables instead
> > of dblink()". I'll cut a long story short by saying that doesn't work for
> > us. We are using postgres_fdw to allo
Robert Haas writes:
> All that having been said, it wouldn't be crazy to try to invent a
> system to lock this down, but it *would* be complicated. An
> individual FDW can call its authentication-related options anything it
> likes; they do not need to be called 'password'. So we'd need a way
>
On Tue, Feb 3, 2015 at 6:26 PM, Noah Yetter wrote:
> The obvious objection is, "well you should just use foreign tables instead
> of dblink()". I'll cut a long story short by saying that doesn't work for
> us. We are using postgres_fdw to allow our analysts to run queries against
> AWS Redshift
12 matches
Mail list logo
