On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
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
2009/8/6 Sam Mason s...@samason.me.uk:
On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
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?
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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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/) {
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
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 not
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 the
Sam Mason s...@samason.me.uk 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
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 it
Sam Mason s...@samason.me.uk 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
On Wed, Aug 05, 2009 at 11:32:06AM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk 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
Sam Mason s...@samason.me.uk 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
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-octet
Sam Mason s...@samason.me.uk 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.
Sam Mason s...@samason.me.uk 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
Sam Mason s...@samason.me.uk 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,
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
Sam Mason s...@samason.me.uk 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
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
Alvaro Herrera alvhe...@commandprompt.com 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
2009/8/5 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
On Tue, Aug 4, 2009 at 4:05 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 rather
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 table
Robert Haas robertmh...@gmail.com 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
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
On Tue, Aug 4, 2009 at 5:23 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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,
and
-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
Josh Berkus j...@agliodbs.com 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
Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 4, 2009 at 11:28 PM, Tom Lanet...@sss.pgh.pa.us 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
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 should be
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 you
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 GUC
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
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 want
On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drakej...@commandprompt.com 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
On Tue, Aug 04, 2009 at 09:16:23PM -0400, Robert Haas wrote:
On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drakej...@commandprompt.com 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
David Fetter da...@fetter.org 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
On Wed, Aug 5, 2009 at 2:43 AM, Tom Lanet...@sss.pgh.pa.us 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
2009/8/5 Alvaro Herrera alvhe...@commandprompt.com:
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
48 matches
Mail list logo
