"Kevin Grittner" wrote:
> From what I could find on a quick scan:
>
> RETURNED_SQLSTATE
> CLASS_ORIGIN
> SUBCLASS_ORIGIN
> CONSTRAINT_CATALOG
> CONSTRAINT_SCHEMA
> CONSTRAINT_NAME
> CATALOG_NAME
> SCHEMA_NAME
> TABLE_NAME
> COLUMN_NAME
> CURSOR_NAME
> MESSAGE_TEXT
> MESSAGE_LENGTH
> MESSAGE_OCT
Tom Lane wrote:
> I'm not proposing that we implement GET DIAGNOSTICS as a statement.
> I was just thinking that the list of values it's supposed to make
> available might do as a guide to what extra error fields we need to
> provide where.
>From what I could find on a quick scan:
RETURNED_S
On Thu, Aug 06, 2009 at 11:41:55AM +0200, Pavel Stehule wrote:
> typically in SQL/PSM (stored procedures - look on GET DIAGNOSTICS
> statement in plpgsql doc), maybe in ecpg. Other's environments raise
> exception - so you can get some data from exception or from special
> structures related to env
2009/8/6 Sam Mason :
> On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
>> 2009/8/5 Tom Lane :
>> > Peter pointed out upthread that the SQL standard already calls out some
>> > things that should be available in this way --- has anyone studied that
>> > yet?
>>
>> yes - it's part of G
On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
> 2009/8/5 Tom Lane :
> > Peter pointed out upthread that the SQL standard already calls out some
> > things that should be available in this way --- has anyone studied that
> > yet?
>
> yes - it's part of GET DIAGNOSTICS statement
>
2009/8/5 Tom Lane :
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Peter pointed out upthread that the SQL standard already calls out some
>>> things that should be available in this way --- has anyone studied that
>>> yet?
>
>> Yeah, I gave it a look. It looks useful as a guide, though obviousl
Alvaro Herrera writes:
> Tom Lane wrote:
>> Peter pointed out upthread that the SQL standard already calls out some
>> things that should be available in this way --- has anyone studied that
>> yet?
> Yeah, I gave it a look. It looks useful as a guide, though obviously
> not directly implementab
Tom Lane wrote:
> Peter pointed out upthread that the SQL standard already calls out some
> things that should be available in this way --- has anyone studied that
> yet?
Yeah, I gave it a look. It looks useful as a guide, though obviously
not directly implementable because it relies on GET DIAG
2009/8/5 Tom Lane :
> Sam Mason writes:
>> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>>> Anyway, it was a bad suggestion that we provide a way to specify a
>>> SQLSTATE to use for a constraint failure. I do think that some field
>>> which could be used for that purpose would
Sam Mason wrote:
> Still doesn't really describe the
> engineering rational behind it though.
Well, the distinctions in many cases would be mostly of interest to a
DBA managing a large shop who was trying to characterize the reasons
for query failure. Some codes, however, are particularly va
Sam Mason writes:
> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>> From the table, the 23xxx series is for integrity constraint
>> violations, but they appear not to have gotten too specific about
>> breaking that down; thereby leaving it as an implementation choice:
> Yes; bu
Sam Mason writes:
> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>> Anyway, it was a bad suggestion that we provide a way to specify a
>> SQLSTATE to use for a constraint failure. I do think that some field
>> which could be used for that purpose would be good. Preferably
>> s
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
> From the spec:
>
> "The character string value returned in an SQLSTATE parameter
> comprises a 2-character class value followed by a 3-character subclass
> value, each with an implementation-defined character set that has a
> one-oc
Sam Mason wrote:
> It just looks like a fixed set of numbers for a fixed set of
> conditions, can't find any canonical definition about what it's
> really for though.
Sorry, I'm familiar with the SQLSTATE's role in the spec, I just
wasn't sure how specific they got in their table of standard v
On Wed, Aug 05, 2009 at 11:32:06AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > Not sure if overloading SQLSTATE is the right way of doing this is
> > it? It already has things like 23514 for a check violation and any
> > other client code relying in this would break if it started getting
Sam Mason wrote:
> Not sure if overloading SQLSTATE is the right way of doing this is
> it? It already has things like 23514 for a check violation and any
> other client code relying in this would break if it started getting
> different things back.
If that's the standard SQLSTATE, I agree -
On Wed, Aug 05, 2009 at 09:30:02AM -0500, Kevin Grittner wrote:
> Anyway, the upshot is -- I think that it would be beneficial to allow,
> to the extent we can confirm it's not a violation of any applicable
> standard, a user-defined SQLSTATE to be associated with a constraint.
> I also think that
Sam Mason wrote:
> On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
>> When you have a full set of constraint, then you don't need to
>> validate input. Just you will execute statement.
>
> Constraints are different from input validation as they rely on
> state that the database'
On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
> > What are people doing with parsing error messages for "column names for
> > datatype mismatches"? I can't imagine any of my code being able to do
> > anything sensible in such a case. If it's things like people giving
> > dates to t
>
> What are people doing with parsing error messages for "column names for
> datatype mismatches"? I can't imagine any of my code being able to do
> anything sensible in such a case. If it's things like people giving
> dates to the database in an incorrect format then that's what they get
> for
On Tue, Aug 04, 2009 at 01:12:10PM -0400, Alvaro Herrera wrote:
> First we need several new error message fields: table name, function
> name, constraint name, and so on. One possible way to go about this
> would be to give each new field its own start letter (see
> http://www.postgresql.org/docs/
> Right now, I do this like this:
>
> if ($err =~ /name_of_first_foreign_key/) {
> $r->error_exit('First error message.')
> }
> elsif ($err =~ /name_of_second_foreign_key/) {
> ...
As an aside comment, a bit more regex foo with \b is indicated here :-)
if ($err =~ /\bname_of_first_foreign_key\b
2009/8/5 Alvaro Herrera :
> David Fetter wrote:
>> On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
>> >
>> > > If that's what we're trying to solve, I don't think that adding
>> > > some kind of proprietary shorthand coding is a good idea. If
>> > > we're do to this at all, it
On Wed, Aug 5, 2009 at 2:43 AM, Tom Lane wrote:
> And the funny thing is that the format we transmit this info to the
> client in is really the least interesting or difficult part of the
> whole matter ...
That in a nutshell is the problem with XML in the first place.
--
greg
http://mit.edu/~gss
David Fetter writes:
> On Tue, Aug 04, 2009 at 09:16:23PM -0400, Robert Haas wrote:
>> My serialization format kicks your serialization format's butt!
> I love standards. There are so many to choose from :)
And the funny thing is that the format we transmit this info to the
client in is really
On Tue, Aug 04, 2009 at 09:16:23PM -0400, Robert Haas wrote:
> On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drake wrote:
> >
> >> So, we are just trying to whip into shape explain diagnostics which are
> >> in JSON or XML, and now you want us to exclude XML from this one because
> >> you don't like it
On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drake wrote:
>
>> So, we are just trying to whip into shape explain diagnostics which are
>> in JSON or XML, and now you want us to exclude XML from this one because
>> you don't like it? Can we please try for some consistency?
>>
>> Sorry to break it to yo
> So, we are just trying to whip into shape explain diagnostics which are
> in JSON or XML, and now you want us to exclude XML from this one because
> you don't like it? Can we please try for some consistency?
>
> Sorry to break it to you, but there are plenty of people and businesses
> who wa
David Fetter wrote:
On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If that's what we're trying to solve, I don't think that adding
some kind of proprietary shorthand coding is a good idea. If
we're do to this
David Fetter wrote:
> On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
> >
> > > If that's what we're trying to solve, I don't think that adding
> > > some kind of proprietary shorthand coding is a good idea. If
> > > we're do to this at all, it should be a connection-based GU
Greg Stark wrote:
> So an alternate proposal is to add a field in the error message which
> contains the untranslated string. That would let applications always
> look at the untranslated string for parsing and always use the
> translated string for user displays.
That's an interesting idea, but
On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > If that's what we're trying to solve, I don't think that adding
> > some kind of proprietary shorthand coding is a good idea. If
> > we're do to this at all, it
On Tue, Aug 4, 2009 at 11:28 PM, Tom Lane wrote:
>
> Huh? What he was talking about is providing additional error fields,
> which would presumably be made available via PQresultErrorField in
> libpq, or its kin in other interfaces, and would be totally invisible to
> any client that didn't ask for
Tom Lane wrote:
> A minimum requirement for such a thing, in my opinion, is that
> *every* occurrence of one of the targeted SQLSTATE codes should be
> able to produce the same auxiliary fields with the same meanings.
> If you can't define it that way, then you haven't actually made
> things be
Josh Berkus writes:
> If that's what we're trying to solve, I don't think that adding some
> kind of proprietary shorthand coding is a good idea. If we're do to
> this at all, it should be a connection-based GUC option, and use some
> standard formal like XML fragments.
Huh? What he was talking
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> If that's what we're trying to solve, I don't think that adding some
> kind of proprietary shorthand coding is a good idea. If we're do to
> this at all, it should be a connection-based GUC option, and use some
> standard formal like XML frag
> Hmm, well, I skipped the rationale because it has been requested before.
> For example, we need to give constraint names so that applications can
> tell which unique key is being violated. We need table names on which
> they are being violated. We need column names for datatype mismatches,
> a
On Tue, Aug 4, 2009 at 5:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> Right now, I do this like this:
>
>> if ($err =~ /name_of_first_foreign_key/) {
>> $r->error_exit('First error message.')
>> }
>> elsif ($err =~ /name_of_second_foreign_key/) {
>> ...
>
>> I've always found that a bit icky be
Tom Lane escribió:
> However, I wonder whether we could turn this around. Instead of an
> open-ended project to add an ill-defined collection of fields to an
> ill-defined collection of error cases, maybe we could identify a
> very short list of cases where it's known to be useful to pull a
> spe
Robert Haas writes:
> Right now, I do this like this:
> if ($err =~ /name_of_first_foreign_key/) {
> $r->error_exit('First error message.')
> }
> elsif ($err =~ /name_of_second_foreign_key/) {
> ...
> I've always found that a bit icky because it relies (for example) on
> their not being two cons
On Tuesday 04 August 2009 23:19:24 Tom Lane wrote:
> Also, you completely dodged the question of defining what the fields
> really mean, which would be 100% essential to doing anything automatic
> with the results. If "errtable" sometimes means a table that doesn't
> exist, and sometimes means a t
Tom Lane wrote:
> If there are situations where this info is missing from the
> human-readable message, then sure, let's look into fixing that.
> But the use-case for automatic interpretation of the message
> is just a whole lot smaller than would justify the work.
> To take just one point, I rat
On Tue, Aug 4, 2009 at 4:05 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Lastly, I'm not as sure as you are that the case for these is well made.
>>> In exactly what cases would client code be able to do something useful
>>> with them? Your proposal involves a pretty huge a
Alvaro Herrera writes:
> Tom Lane wrote:
>> It would also help to have clear definitions of what these *mean*, which
>> is entirely unclear from your comments --- in particular, the reference
>> to errcontext callbacks confuses the heck out of me. I would have
>> thought that these would be used
2009/8/4 Tom Lane :
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Lastly, I'm not as sure as you are that the case for these is well made.
>>> In exactly what cases would client code be able to do something useful
>>> with them? Your proposal involves a pretty huge amount of work if we
>>> are
Alvaro Herrera writes:
> Tom Lane wrote:
>> Lastly, I'm not as sure as you are that the case for these is well made.
>> In exactly what cases would client code be able to do something useful
>> with them? Your proposal involves a pretty huge amount of work if we
>> are to carry it out thoroughly,
Tom Lane wrote:
> Alvaro Herrera writes:
> > First we need several new error message fields: table name, function
> > name, constraint name, and so on.
>
> It would also help to have clear definitions of what these *mean*, which
> is entirely unclear from your comments --- in particular, the refe
Alvaro Herrera writes:
> First we need several new error message fields: table name, function
> name, constraint name, and so on.
It would also help to have clear definitions of what these *mean*, which
is entirely unclear from your comments --- in particular, the reference
to errcontext callback
Hi,
I think the case for machine-readable error fields is well made and
doesn't need any further push.
So, what do we need to make it happen? Here's my proposal.
First we need several new error message fields: table name, function
name, constraint name, and so on. One possible way to go about
49 matches
Mail list logo
