2011/5/11 Shigeru Hanada :
> (2011/04/26 5:42), Robert Haas wrote:
>> OK. Turned out a little more cleanup was needed to make this all the
>> way consistent with how we handle views; I have now done that.
>
> I noticed that some fixes would be needed for consistency about foreign
> table privilege
(2011/04/26 5:42), Robert Haas wrote:
> OK. Turned out a little more cleanup was needed to make this all the
> way consistent with how we handle views; I have now done that.
I noticed that some fixes would be needed for consistency about foreign
table privileges. Attached patch includes fixes bel
On Mon, Apr 25, 2011 at 2:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... There's a similar stanza for sequences, but that one uses
>> ereport(WARNING...) rather than ereport(ERROR...). We could either
>> remove that stanza entirely (making foreign tables consistent with
>> views) or change
On Mon, Apr 25, 2011 at 7:02 PM, Tom Lane wrote:
> Yeah, the existing precedent (not only for GRANT but for some other
> things like ALTER TABLE) is that a command that says "TABLE" is allowed
> to apply to other relation types if it makes sense to apply it. It's
> only when you name some other o
Robert Haas writes:
> ... There's a similar stanza for sequences, but that one uses
> ereport(WARNING...) rather than ereport(ERROR...). We could either
> remove that stanza entirely (making foreign tables consistent with
> views) or change ERROR to WARNING (making it consistent with
> sequences)
On Mon, Apr 25, 2011 at 2:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane wrote:
>> I'm not sure I quite understood what you were saying there, but I'm
>> coming around to the view that this is already 100% consistent with
>> the way views are handled:
>
On mån, 2011-04-25 at 13:35 -0400, Robert Haas wrote:
> Hmm, it appears we had some pre-existing inconsistency here, because
> ALL TABLES IN currently includes views.
Which makes sense because you use GRANT ... ON TABLE to grant privileges
to views.
> That's weird, but
> it'll be even more weird
Robert Haas writes:
> On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane wrote:
> I'm not sure I quite understood what you were saying there, but I'm
> coming around to the view that this is already 100% consistent with
> the way views are handled:
> rhaas=# create view v as select 1;
> CREATE VIEW
> rha
On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm, it appears we had some pre-existing inconsistency here, because
>> ALL TABLES IN currently includes views. That's weird, but
>> it'll be even more weird if we adopt the approach suggested by this
>> patch, which crea
Robert Haas writes:
> Hmm, it appears we had some pre-existing inconsistency here, because
> ALL TABLES IN currently includes views. That's weird, but
> it'll be even more weird if we adopt the approach suggested by this
> patch, which creates ALL FOREIGN TABLES IN but allows ALL
> TABLES IN t
On Wed, Apr 20, 2011 at 11:08 AM, Robert Haas wrote:
> On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane wrote:
>> Shigeru Hanada writes:
>>> Attached patch implements along specifications below. It also includes
>>> documents and regression tests. Some of regression tests might be
>>> redundant and r
On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane wrote:
> Shigeru Hanada writes:
>> Attached patch implements along specifications below. It also includes
>> documents and regression tests. Some of regression tests might be
>> redundant and removable.
>
>> 1) "GRANT privilege [(column_list)] ON [TABLE
Shigeru Hanada writes:
> Attached patch implements along specifications below. It also includes
> documents and regression tests. Some of regression tests might be
> redundant and removable.
> 1) "GRANT privilege [(column_list)] ON [TABLE] TO role" also work for
> foreign tables as well as r
(2011/04/15 3:43), Robert Haas wrote:
On Fri, Apr 1, 2011 at 1:29 AM, Shigeru HANADA
wrote:
In addition to the 2nd GRANT above, "GRANT SELECT (colour) ON stuff TO
user_a" (omitting TABLE) will succeed too because parser assumes that
the target object is a regular table if object type was TABLE
On Thu, Apr 14, 2011 at 8:26 PM, Tom Lane wrote:
> 1. Accepting non-functional constraint declarations is something we've
> been heard to ridicule mysql for. With good reason.
>
> 2. It probably won't be too long before the planner makes optimization
> decisions that assume NOT NULL declarations
On 15 April 2011 04:26, Tom Lane wrote:
> Why is this a documentation issue and not a code issue? IMO we should
> flat out reject both NOT NULL and DEFAULT declarations on foreign
> tables, until such time as we're prepared to do something useful with
> them. Reasons:
If the removal the redunda
Robert Haas writes:
> On Fri, Apr 1, 2011 at 5:13 AM, Thom Brown wrote:
>> On 1 April 2011 12:57, Shigeru HANADA wrote:
>>> NOT NULL constraint on foreign table is just declaration and can't
>>> force data integrity. And I noticed that CREATE FOREIGN TABLE
>>> document doesn't mention that seri
On Fri, Apr 1, 2011 at 1:29 AM, Shigeru HANADA
wrote:
> In addition to the 2nd GRANT above, "GRANT SELECT (colour) ON stuff TO
> user_a" (omitting TABLE) will succeed too because parser assumes that
> the target object is a regular table if object type was TABLE or
> omitted. This inconsistent beh
On Fri, Apr 1, 2011 at 5:13 AM, Thom Brown wrote:
> On 1 April 2011 12:57, Shigeru HANADA wrote:
>> NOT NULL constraint on foreign table is just declaration and can't
>> force data integrity. And I noticed that CREATE FOREIGN TABLE
>> document doesn't mention that serial and bigserial can't be u
On 1 April 2011 12:57, Shigeru HANADA wrote:
> NOT NULL constraint on foreign table is just declaration and can't
> force data integrity. And I noticed that CREATE FOREIGN TABLE
> document doesn't mention that serial and bigserial can't be used in
> foreign table. Please see foreign_table_doc.pa
On Fri, 1 Apr 2011 01:24:20 +0100
Thom Brown wrote:
> Also, there probably needs to be some elaboration of how a NOT NULL
> declaration operates on a foreign table column on the CREATE FOREIGN
> TABLE reference page. From what I can see, if the foreign table
> cannot be modified such as those def
On Fri, 1 Apr 2011 00:54:18 +0100
Thom Brown wrote:
> I've noticed some weirdness when trying to grant various types of
> permissions on a foreign table and thought I'd report it here:
>
> postgres=# \d stuff
> Foreign table "public.stuff"
> Column | Type | Modifiers
> +-+---
On 1 April 2011 00:54, Thom Brown wrote:
> Hi,
>
> I've noticed some weirdness when trying to grant various types of
> permissions on a foreign table and thought I'd report it here:
>
> postgres=# \d stuff
> Foreign table "public.stuff"
> Column | Type | Modifiers
> +-+---
Hi,
I've noticed some weirdness when trying to grant various types of
permissions on a foreign table and thought I'd report it here:
postgres=# \d stuff
Foreign table "public.stuff"
Column | Type | Modifiers
+-+---
id | integer |
colour | text|
animal | tex
24 matches
Mail list logo
