Excerpts from Robert Haas's message of lun ene 03 12:21:44 -0300 2011:
> Yeah, that's no good. Maybe there's a good way to clear things up
> with an errdetail(), though I'm having a hard time thinking how to
> phrase it.
>
> ERROR: sequence "%s" does not support the requested operation
> DETAIL:
On Sun, Jan 2, 2011 at 4:45 PM, Peter Eisentraut wrote:
> On lör, 2011-01-01 at 17:21 -0500, Robert Haas wrote:
>> > I don't see anything wrong with having 20 or 30 messages of variants of
>> >
>> > "foo cannot be used on bar"
>> >
>> > without placeholders.
>>
>> Well, that's OK with me. It seem
On lör, 2011-01-01 at 17:21 -0500, Robert Haas wrote:
> > I don't see anything wrong with having 20 or 30 messages of variants of
> >
> > "foo cannot be used on bar"
> >
> > without placeholders.
>
> Well, that's OK with me. It seems a little grotty, but manageably so.
> Questions:
>
> 1. Shoul
On Sat, Jan 1, 2011 at 4:28 PM, Peter Eisentraut wrote:
> On lör, 2011-01-01 at 00:05 -0500, Robert Haas wrote:
>> Yeah, and I still believe that. I'm having difficulty coming up with
>> a workable approach, though.
>
> I don't see anything wrong with having 20 or 30 messages of variants of
>
> "
On lör, 2011-01-01 at 10:00 -0500, Robert Haas wrote:
> Is it in any better if we write one string per feature, like this:
>
> constraints cannot be used on %s
> triggers cannot be used on %s
>
> ...where %s is a plural object type (views, foreign tables, etc.).
No, this won't work.
--
Sent v
On lör, 2011-01-01 at 00:05 -0500, Robert Haas wrote:
> Yeah, and I still believe that. I'm having difficulty coming up with
> a workable approach, though.
I don't see anything wrong with having 20 or 30 messages of variants of
"foo cannot be used on bar"
without placeholders.
--
Sent via pg
Le 01/01/2011 16:00, Robert Haas a écrit :
> On Sat, Jan 1, 2011 at 9:53 AM, Guillaume Lelarge
> wrote:
>> Le 01/01/2011 06:05, Robert Haas a écrit :
>>> On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
> No, quite the opposit
On Sat, Jan 1, 2011 at 9:53 AM, Guillaume Lelarge
wrote:
> Le 01/01/2011 06:05, Robert Haas a écrit :
>> On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
>>> On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
No, quite the opposite. With the other approach, you needed:
Le 01/01/2011 06:05, Robert Haas a écrit :
> On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
>> On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
>>> No, quite the opposite. With the other approach, you needed:
>>>
>>> constraints cannot be used on views
>>> constraints cannot be use
On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
> On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
>> No, quite the opposite. With the other approach, you needed:
>>
>> constraints cannot be used on views
>> constraints cannot be used on composite types
>> constraints cannot be used
On tor, 2010-12-30 at 11:49 -0500, Tom Lane wrote:
> ISTM there are four things we might potentially want to state in the
> error message: the feature/operation you tried to apply, the name of
> the object you tried to apply it to, the type of that object, and the
> set of object types that the fea
On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
> No, quite the opposite. With the other approach, you needed:
>
> constraints cannot be used on views
> constraints cannot be used on composite types
> constraints cannot be used on TOAST tables
> constraints cannot be used on indexes
> const
On Fri, Dec 31, 2010 at 8:10 AM, Alvaro Herrera
wrote:
>> I think for now what I
>> had better do is try to get this SQL/MED patch finished up by
>> soldiering through this mess rather than trying to fix it. I think
>> it's going to be kind of ugly, but we haven't got another plan then
>> we're j
Excerpts from Robert Haas's message of vie dic 31 02:07:18 -0300 2010:
> I think that's true in some cases but not all. The system-generated
> attribute names thing actually applies in several cases, and I think
> it's pretty cut-and-dried. When you get into something like which
> kinds of relat
On Thu, Dec 30, 2010 at 9:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think this thread has worked itself around to where it's entirely
>> pointless.
>
> I understand your frustration, but it's not clear to me that there *is*
> any simple solution to this problem. Fundamentally, adding new
Robert Haas writes:
> I think this thread has worked itself around to where it's entirely
> pointless.
I understand your frustration, but it's not clear to me that there *is*
any simple solution to this problem. Fundamentally, adding new relkinds
to the system is always going to require running
On Thu, Dec 30, 2010 at 8:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On further reflection, this can still turn into a laundry list in certain
>> cases.
>
>> DETAIL: You can only comment on columns of tables, views, and composite
>> types.
>
>> seems less helpful than:
>
>> DETAIL: Comment
Robert Haas writes:
> On further reflection, this can still turn into a laundry list in certain
> cases.
> DETAIL: You can only comment on columns of tables, views, and composite types.
> seems less helpful than:
> DETAIL: Comments on relations with system-generated column names are
> not supp
On Thu, Dec 30, 2010 at 12:32 PM, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane wrote:
>> One possibility is to break it down like this:
>>
>> ERROR: foo is a sequence
>> DETAIL: Triggers can only be used on tables and views.
>>
>> This could still be emitted by a
On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane wrote:
> One possibility is to break it down like this:
>
> ERROR: foo is a sequence
> DETAIL: Triggers can only be used on tables and views.
>
> This could still be emitted by a function such as you suggest, and
> indeed that would be the m
Excerpts from Tom Lane's message of jue dic 30 13:49:20 -0300 2010:
> One possibility is to break it down like this:
>
> ERROR: foo is a sequence
> DETAIL: Triggers can only be used on tables and views.
>
> This could still be emitted by a function such as you suggest, and
> indeed that
Robert Haas writes:
> After further thought, I think it makes sense to change this around a
> bit and create a family of functions that can be invoked like this:
> void check_relation_for_FEATURE_support(Relation rel);
That seems like a reasonable idea, but ...
> ... The error message will be of
On Thu, Dec 30, 2010 at 11:00 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue dic 30 12:47:42 -0300 2010:
>
>> After further thought, I think it makes sense to change this around a
>> bit and create a family of functions that can be invoked like this:
>>
>> void check_relati
Excerpts from Robert Haas's message of jue dic 30 12:47:42 -0300 2010:
> After further thought, I think it makes sense to change this around a
> bit and create a family of functions that can be invoked like this:
>
> void check_relation_for_FEATURE_support(Relation rel);
>
> ...where FEATURE is
On Wed, Dec 29, 2010 at 5:14 PM, David Fetter wrote:
> On Wed, Dec 29, 2010 at 04:53:47PM -0500, Robert Haas wrote:
>> On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
>> wrote:
>> > On 29.12.2010 06:54, Robert Haas wrote:
>> >>
>> >> With the patch:
>> >>
>> >> rhaas=# cluster v;
>> >> ERROR
On Wed, Dec 29, 2010 at 04:53:47PM -0500, Robert Haas wrote:
> On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
> wrote:
> > On 29.12.2010 06:54, Robert Haas wrote:
> >>
> >> With the patch:
> >>
> >> rhaas=# cluster v;
> >> ERROR: views do not support CLUSTER
> >
> > "do not support" sounds
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
wrote:
> On 29.12.2010 06:54, Robert Haas wrote:
>>
>> With the patch:
>>
>> rhaas=# cluster v;
>> ERROR: views do not support CLUSTER
>
> "do not support" sounds like a missing feature, rather than a nonsensical
> command. How about something
On Wed, Dec 29, 2010 at 3:01 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
>>> In practice I think it would make sense if heap_open accepts all
>>> relation types on which you can potentially do either a heapscan or
>>> indexsc
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
>> In practice I think it would make sense if heap_open accepts all
>> relation types on which you can potentially do either a heapscan or
>> indexscan (offhand those should be the same set of relkinds, I
Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
> In practice I think it would make sense if heap_open accepts all
> relation types on which you can potentially do either a heapscan or
> indexscan (offhand those should be the same set of relkinds, I think;
> so this is the same
Robert Haas writes:
> The existing comments mention that callers must check that the return
> value is not a view, if they care. So if there is currently a single
> coherent definition for what heap_open is supposed to do, it's clearly
> NOT the one Heikki proposes. My guess is that reality is c
On Dec 29, 2010, at 12:49 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hmm, I believe the idea of heap_open is to check that the relation is
>> backed by a heap that you can read with heap_beginscan+heap_next. At the
>> moment that includes normal tables, sequences and toast tables. Fore
Heikki Linnakangas writes:
> Hmm, I believe the idea of heap_open is to check that the relation is
> backed by a heap that you can read with heap_beginscan+heap_next. At the
> moment that includes normal tables, sequences and toast tables. Foreign
> tables would not fall into that category.
I
On 29.12.2010 13:17, Robert Haas wrote:
Did you read the whole thread?
Ah, sorry:
I've had to change some of the heap_open(rv) calls to
relation_open(rv) to avoid having the former throw the wrong error
message before the latter kicks in. I think there might be stylistic
objections to that,
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
wrote:
> On 29.12.2010 06:54, Robert Haas wrote:
>>
>> With the patch:
>>
>> rhaas=# cluster v;
>> ERROR: views do not support CLUSTER
>
> "do not support" sounds like a missing feature, rather than a nonsensical
> command. How about something
On 29.12.2010 06:54, Robert Haas wrote:
With the patch:
rhaas=# cluster v;
ERROR: views do not support CLUSTER
"do not support" sounds like a missing feature, rather than a
nonsensical command. How about something like "CLUSTER cannot be used on
views"
The patch changes a bunch of heap_
On Mon, Dec 27, 2010 at 2:06 PM, Robert Haas wrote:
> The problem is that alter table actions AT_AddIndex and
> AT_AddConstraint don't tie neatly back to a particular piece of
> syntax. The message as written isn't incomprehensible (especially if
> you're reading it in English) but it definitely
On Mon, Dec 27, 2010 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> or if we go with the some-assembly required version, perhaps:
>
>> "tables do not support %s"
>> "views do not support %s"
>> "indexes do not support %s"
>
> +1 for that way. Although personally I'd reverse the phrasing:
Robert Haas writes:
> or if we go with the some-assembly required version, perhaps:
> "tables do not support %s"
> "views do not support %s"
> "indexes do not support %s"
+1 for that way. Although personally I'd reverse the phrasing:
/* translator: %s is the name of a SQL command */
On Dec 26, 2010, at 7:55 PM, Robert Haas wrote:
> "tables do not support %s"
> "views do not support %s"
> "indexes do not support %s"
The more detail we can give, the better, of course. Nothing's more frustrating
than having a command with an error like, "Object does not support requested
op
On Sun, Dec 26, 2010 at 10:44 PM, Itagaki Takahiro
wrote:
> On Mon, Dec 27, 2010 at 12:13, Robert Haas wrote:
>> Could we get away with something as simple as "requested operation is
>> not supported for "?
>
> +1. If so, will we have a function to get object names something like
> GetPluralFormO
On Mon, Dec 27, 2010 at 12:13, Robert Haas wrote:
> Could we get away with something as simple as "requested operation is
> not supported for "?
+1. If so, will we have a function to get object names something like
GetPluralFormOfObjectType(Relation rel or char relkind) => char * ?
> But that b
On Sun, Dec 26, 2010 at 10:13:35PM -0500, Robert Haas wrote:
> In reviewing the work Shigeru Hanada has done on SQL/MED, it's come to
> my attention that we have a lot of error messages that use the error
> code ERRCODE_WRONG_OBJECT_TYPE and have text like this:
>
> "%s" is not a table
> "%s" is
In reviewing the work Shigeru Hanada has done on SQL/MED, it's come to
my attention that we have a lot of error messages that use the error
code ERRCODE_WRONG_OBJECT_TYPE and have text like this:
"%s" is not a table
"%s" is not an index
or even better:
"%s" is not a table, view, composite type,
44 matches
Mail list logo
