Tom Lane wrote:
> I think Peter's got the error and the detail backwards. It should be
> more like
>
> ERROR: "someview" cannot have constraints
> DETAIL: "someview" is a view.
>
> If we do it like that, we need one ERROR message per error reason,
> and one DETAIL per relkind, which should be m
Joe Conway wrote:
> On 08/02/2017 10:52 PM, Ashutosh Bapat wrote:
> > On Wed, Aug 2, 2017 at 11:15 PM, Alvaro Herrera
> > wrote:
> >> Alvaro Herrera wrote:
> >>> I think pg_class is a reasonable place to put more generic relkind lists
> >>> alongside a matching error message for each, rather than
On 08/02/2017 10:52 PM, Ashutosh Bapat wrote:
> On Wed, Aug 2, 2017 at 11:15 PM, Alvaro Herrera
> wrote:
>> Alvaro Herrera wrote:
>>> I think pg_class is a reasonable place to put more generic relkind lists
>>> alongside a matching error message for each, rather than specialized
>>> "does this rel
On 08/02/2017 10:30 PM, Ashutosh Bapat wrote:
> On Wed, Aug 2, 2017 at 8:47 PM, Robert Haas wrote:
>> 0001-RELKIND_HAS_VISIBILITY_MAP.patch - one place
>> 0002-RELKIND_HAS_STORAGE.patch - one place
>> 0003-RELKIND_HAS_XIDS-macro.patch - one place
>> 0004-RELKIND_HAS_COMPOSITE_TYPE-macro.patch - on
On Wed, Aug 2, 2017 at 11:15 PM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>> I think pg_class is a reasonable place to put more generic relkind lists
>> alongside a matching error message for each, rather than specialized
>> "does this relkind have storage" macros. What about something like
On Wed, Aug 2, 2017 at 10:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> I've thought about this kind of thing, too. But the thing is that
>> most of these macros you're proposing to introduce only get used in
>> one place.
>
> I think the value would be in having a centralized checklist of
> t
On Wed, Aug 2, 2017 at 8:47 PM, Robert Haas wrote:
> On Mon, Jul 3, 2017 at 3:52 AM, Ashutosh Bapat
> wrote:
>>> I noticed, that
>>> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
>>> number of conditions to include this relkind. We missed some places in
>>> initial commi
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> The actual error, from the perspective of the user, is something like
>> ERROR: "someview" is a view
>> DETAIL: Views cannot have constraints.
> OK. "%s is a %s" is a reasonable set of errors -- we just need one for
> each relkind. So the firs
Peter Eisentraut wrote:
> I don't find this style of error message optimal anyway. If I do, for
> example
>
> ALTER TABLE someview ADD CONSTRAINT ...
> ERROR: "someview" is not a table, foreign table, whatever
>
> then this information is not helpful. It's not like I'm going to turn
> my view
Alvaro Herrera wrote:
> I think pg_class is a reasonable place to put more generic relkind lists
> alongside a matching error message for each, rather than specialized
> "does this relkind have storage" macros. What about something like a
> struct list in pg_class.h,
I just noticed that this does
On 8/2/17 13:28, Alvaro Herrera wrote:
> I think pg_class is a reasonable place to put more generic relkind lists
> alongside a matching error message for each, rather than specialized
> "does this relkind have storage" macros. What about something like a
> struct list in pg_class.h,
>
> {
>
I think pg_class is a reasonable place to put more generic relkind lists
alongside a matching error message for each, rather than specialized
"does this relkind have storage" macros. What about something like a
struct list in pg_class.h,
{
{
relkinds_r_i_T,
{ 'r', 'i', 'T' },
Robert Haas writes:
> I've thought about this kind of thing, too. But the thing is that
> most of these macros you're proposing to introduce only get used in
> one place.
I think the value would be in having a centralized checklist of
things-to-fix-when-adding-a-new-relkind. There's more than o
On Mon, Jul 3, 2017 at 3:52 AM, Ashutosh Bapat
wrote:
>> I noticed, that
>> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
>> number of conditions to include this relkind. We missed some places in
>> initial commits and fixed those later. I am wondering whether we
>> shoul
Forgot to attach the patch with the earlier mail.
On Mon, Jul 3, 2017 at 1:22 PM, Ashutosh Bapat
wrote:
> On Mon, May 29, 2017 at 12:55 PM, Ashutosh Bapat
> wrote:
>>
>> --
>> I noticed, that
>> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
>> number of conditions to inc
On Mon, May 29, 2017 at 12:55 PM, Ashutosh Bapat
wrote:
>
> --
> I noticed, that
> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
> number of conditions to include this relkind. We missed some places in
> initial commits and fixed those later. I am wondering whether we
> sh
16 matches
Mail list logo