On 1/28/13 11:08 PM, Tom Lane wrote:
The issue is that
this definition presupposes that we want to complain about a table or
a domain, never both, because we're overloading both the SCHEMA_NAME
and CONSTRAINT_NAME fields for both purposes. This is annoying in
validateDomainConstraint(),
2013/1/27 Tom Lane t...@sss.pgh.pa.us:
Peter Geoghegan peter.geoghega...@gmail.com writes:
On 26 January 2013 22:36, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, one thing that struck me in a quick look-through is that the
ERRCODE_FOREIGN_KEY_VIOLATION patches seem to inconsistently send
either
2013/1/28 Peter Geoghegan peter.geoghega...@gmail.com:
On 28 January 2013 21:33, Peter Eisentraut pete...@gmx.net wrote:
Another point, in case someone wants to revisit this in the future, is
that these fields were applied in a way that is contrary to the SQL
standard, I think.
The presented
On 29 January 2013 17:05, Pavel Stehule pavel.steh...@gmail.com wrote:
Perhaps I'm mistaken, but I can't imagine that it would be terribly
useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
ROUTINE_NAME.
I hoped so I can use it inside exception handler
Right, but is that
2013/1/29 Peter Geoghegan peter.geoghega...@gmail.com:
On 29 January 2013 17:05, Pavel Stehule pavel.steh...@gmail.com wrote:
Perhaps I'm mistaken, but I can't imagine that it would be terribly
useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
ROUTINE_NAME.
I hoped so I can
I wrote:
Rather what we've got is that constraints are uniquely named among
those associated with a table, or with a domain. So the correct
unique key for a table constraint is table schema + table name +
constraint name, whereas for a domain constraint it's domain schema +
domain name +
I wrote:
Here's an updated patch (code only, sans documentation) that fixes that
and adds some other refactoring that I thought made for improvements.
I think this is ready to commit except for the documentation.
Pushed with documentation.
regards, tom lane
--
Sent
A couple more things about this patch ...
I went back through the thread and reviewed all the angst about which
fields to provide, especially whether we need CONSTRAINT_SCHEMA.
I agree with the conclusion that we don't. It's in the spec because
the spec supposes that
2013/1/28 Tom Lane t...@sss.pgh.pa.us:
A couple more things about this patch ...
I went back through the thread and reviewed all the angst about which
fields to provide, especially whether we need CONSTRAINT_SCHEMA.
I agree with the conclusion that we don't. It's in the spec because
the
Pavel Stehule pavel.steh...@gmail.com writes:
2013/1/28 Tom Lane t...@sss.pgh.pa.us:
... The current patch provides sufficient
information to uniquely identify a table constraint, but not so much
domain constraints. Should we fix that? I think it'd be legitimate
to re-use SCHEMA_NAME for
2013/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2013/1/28 Tom Lane t...@sss.pgh.pa.us:
... The current patch provides sufficient
information to uniquely identify a table constraint, but not so much
domain constraints. Should we fix that? I think it'd be
On 1/5/13 12:48 PM, Peter Geoghegan wrote:
is there agreement of routine_name and trigger_name fields?
Well, Tom and I are both opposed to including those fields. Peter E
seemed to support it in some way, but didn't respond to Tom's
criticisms (which were just a restatement of my own). So, it
On 28 January 2013 21:33, Peter Eisentraut pete...@gmx.net wrote:
Another point, in case someone wants to revisit this in the future, is
that these fields were applied in a way that is contrary to the SQL
standard, I think.
The presented patch interpreted ROUTINE_NAME as: the error happened
I wrote:
Rather what we've got is that constraints are uniquely named among
those associated with a table, or with a domain. So the correct
unique key for a table constraint is table schema + table name +
constraint name, whereas for a domain constraint it's domain schema +
domain name +
Peter Geoghegan peter.geoghega...@gmail.com writes:
On 26 January 2013 22:36, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to remove the requirements business altogether and just
document that these fields may be supplied, or words to that effect.
I think we may be talking at cross
On 27 January 2013 18:57, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan peter.geoghega...@gmail.com writes:
I think we may be talking at cross purposes here. Guarantee may have
been too strong a word, or the wrong word entirely. All that I really
want here is for there to be a coding
Peter Geoghegan peter.geoghega...@gmail.com writes:
On 26 January 2013 22:36, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, one thing that struck me in a quick look-through is that the
ERRCODE_FOREIGN_KEY_VIOLATION patches seem to inconsistently send
either the PK or FK rel as the errtable. Is this
Peter Geoghegan peter.geoghega...@gmail.com writes:
On 27 January 2013 18:57, Tom Lane t...@sss.pgh.pa.us wrote:
However, this patch is not that, and mere documentation isn't going to buy a
thing here IMO. Especially not user-facing documentation, as opposed
to something that might be in a
Peter Geoghegan pe...@2ndquadrant.com writes:
[ eelog6.patch ]
So, with the question of what fields to include and whether constraint
name needs to be unambiguously resolvable addressed (I think), it
appears that I've brought this one as far as I can. I'd still like to
get input from a Perl
On 26 January 2013 22:36, Tom Lane t...@sss.pgh.pa.us wrote:
I started to look this patch over. I think we can get to something
committable from here, but I'm having a problem with the concept that
we're going to guarantee anything about which additional fields might
be available for any
Hello
From my perspective - the core of this patch has two parts
a) necessary infrastructure
b) enhancing current ereport calls
@a point is important for me and plpgsql coders, because it allows
using these fields in custom PL/pgSQL exception - and errors
processing in this language can be more
Hello
Personally, on the face of it I'd expect the inconsistency to simply
reflect the fact that the error related to the referencing table or
referenced table. Pavel's original patch followed the same convention
(though it also had a constraint_table field). I'm having a hard time
figuring
On 13 January 2013 06:13, Pavel Stehule pavel.steh...@gmail.com wrote:
Not sure, but I don't think it matters. You can blame the constraint
implementation, but that doesn't change my feelings about what we need
before we can accept a patch like this. Providing something which works
only part
Peter Geoghegan pe...@2ndquadrant.com writes:
I felt that this was quite unnecessary because of the limited scope of
the patch, and because this raises thorny issues of both semantics and
implementation. Tom agreed with this general view - after all, this
patch exists for the express purpose
Hello
2012/12/29 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
it is a problem of this patch or not consistent constraints implementation ?
Not sure, but I don't think it matters. You can blame the constraint
implementation, but that doesn't change my
Hello
2013/1/4 Robert Haas robertmh...@gmail.com:
On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
Now, as to the question of whether we need to make sure that
everything is always fully qualified - I respectfully disagree with
Stephen, and maintain my position
2013/1/4 Peter Geoghegan pe...@2ndquadrant.com:
On 4 January 2013 18:07, Tom Lane t...@sss.pgh.pa.us wrote:
Exactly. To my mind, the *entire* point of this patch is to remove the
need for people to try to dig information out of potentially-localized
message strings. It's not clear to me that
On 5 January 2013 16:56, Pavel Stehule pavel.steh...@gmail.com wrote:
It seems that we're in agreement, then. I'll prepare a version of the
patch very similar to the one I previously posted, but with some
caveats about how reliably the values can be used. I think that that
should be fine.
is
2013/1/5 Peter Geoghegan pe...@2ndquadrant.com:
On 5 January 2013 16:56, Pavel Stehule pavel.steh...@gmail.com wrote:
It seems that we're in agreement, then. I'll prepare a version of the
patch very similar to the one I previously posted, but with some
caveats about how reliably the values can
On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Now, as to the question of whether we need to make sure that
everything is always fully qualified - I respectfully disagree with
Stephen, and maintain my position set out in the last round of
feedback [1], which is
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Ascertaining the identity of the object in question perfectly
unambiguously, so that you can safely do something like lookup a
comment on the object, seems like something way beyond what I'd
envisioned for this
Robert Haas robertmh...@gmail.com schrieb:
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
pe...@2ndquadrant.com wrote:
Ascertaining the identity of the object in question perfectly
unambiguously, so that you can safely do something like lookup a
comment on the object, seems like something
anara...@anarazel.de and...@anarazel.de writes:
Robert Haas robertmh...@gmail.com schrieb:
The people who are content to do that don't need this patch at all.
They can just apply a regexp to the message that comes back from the
server and then set constraint_name based on what pops out of the
On 4 January 2013 18:07, Tom Lane t...@sss.pgh.pa.us wrote:
Exactly. To my mind, the *entire* point of this patch is to remove the
need for people to try to dig information out of potentially-localized
message strings. It's not clear to me that we have to strain to provide
information that
On 4 January 2013 17:10, Robert Haas robertmh...@gmail.com wrote:
I don't really agree with this. To be honest, my biggest concern
about this patch is that it will make it take longer to report an
error. At least in the cases where these additional fields are
included, it will take CPU time
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
so - cannot be a solution define CONSTRAINT_TABLE field - constaint
names in table are unique.
Adding a table column, and a schema column, would be ideal. Those would
all be part of the PK and not null'able, but then we wouldn't
necessairly
2012/12/30 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
so - cannot be a solution define CONSTRAINT_TABLE field - constaint
names in table are unique.
Adding a table column, and a schema column, would be ideal. Those would
all be part of the PK and not
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com wrote:
again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
can be useful for some use cases, where developer should to handle
exception when they coming from known functions/triggers and he would
to raise
Peter Geoghegan pe...@2ndquadrant.com writes:
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com wrote:
So I'm with Peter G on this: the existing CONTEXT mechanism is good
enough, we do not need to split out selected sub-parts of that as
separate error fields. Moreover, doing so
2012/12/29 Peter Geoghegan pe...@2ndquadrant.com:
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com wrote:
again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
can be useful for some use cases, where developer should to handle
exception when they coming from
2012/12/29 Tom Lane t...@sss.pgh.pa.us:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com wrote:
So I'm with Peter G on this: the existing CONTEXT mechanism is good
enough, we do not need to split out selected sub-parts of that as
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 28 December 2012 15:57, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that part's been agreed to at all; it seems entirely
possible that it'll get dropped if/when the patch gets committed.
I'm not convinced that having these fields in
On 29 December 2012 17:43, Stephen Frost sfr...@snowman.net wrote:
I'd like to see more options for what is logged, as I've mentioned in
the past, and I think all of these would be good candidates for logging
in some circumstances. The insistence on having one CSV format to rule
them all and
2012/12/29 Peter Geoghegan pe...@2ndquadrant.com:
On 29 December 2012 17:43, Stephen Frost sfr...@snowman.net wrote:
I'd like to see more options for what is logged, as I've mentioned in
the past, and I think all of these would be good candidates for logging
in some circumstances. The
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
Pavel originally included a
constraint_schema field, because he figured that the way constraints
are catalogued necessitated such a field.
That's exactly what I was getting at also- in order to do a lookup in
the catalog, you need to
On 29 December 2012 18:37, Stephen Frost sfr...@snowman.net wrote:
That's exactly what I was getting at also- in order to do a lookup in
the catalog, you need to know certain information to avoid potentially
getting multiple records back (which would be an error...).
Well, Pavel said that
2012/12/29 Peter Geoghegan pe...@2ndquadrant.com:
On 29 December 2012 18:37, Stephen Frost sfr...@snowman.net wrote:
That's exactly what I was getting at also- in order to do a lookup in
the catalog, you need to know certain information to avoid potentially
getting multiple records back (which
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
So, unless someone adds a constraint name outside of these errcodes (I
doubt that would make sense), there is exactly one case where a
constraint_name could not have a schema_name (which, as I've said, is
almost the same thing as
2012/12/29 Stephen Frost sfr...@snowman.net:
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
So, unless someone adds a constraint name outside of these errcodes (I
doubt that would make sense), there is exactly one case where a
constraint_name could not have a schema_name (which, as I've
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Having just constraint_schema and constraint_name feels horribly wrong
as the definition of a constraint also includes a pg_class oid.
but then TABLE_NAME and TABLE_SCHEMA will be defined.
How are you going to look up the constraint? Using
2012/12/29 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Having just constraint_schema and constraint_name feels horribly wrong
as the definition of a constraint also includes a pg_class oid.
but then TABLE_NAME and TABLE_SCHEMA will be defined.
How
On 29 December 2012 19:56, Stephen Frost sfr...@snowman.net wrote:
- that case is
ERRCODE_CHECK_VIOLATION.
That's because this SQL could cause ERRCODE_CHECK_VIOLATION:
select '123'::upc_barcode;
I'm surprised to see that as a constraint violation rather than a domain
violation..?
I was
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
Having just constraint_schema and constraint_name feels horribly wrong
as the definition of a constraint also includes a pg_class oid.
I think that it's probably sufficient *for error handling purposes*.
Since it is non-trivial to get the
2012/12/29 Stephen Frost sfr...@snowman.net:
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
Having just constraint_schema and constraint_name feels horribly wrong
as the definition of a constraint also includes a pg_class oid.
I think that it's probably sufficient *for error handling
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
it is a problem of this patch or not consistent constraints implementation ?
Not sure, but I don't think it matters. You can blame the constraint
implementation, but that doesn't change my feelings about what we need
before we can accept a patch
2012/12/29 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
it is a problem of this patch or not consistent constraints implementation ?
Not sure, but I don't think it matters. You can blame the constraint
implementation, but that doesn't change my feelings
On 29 December 2012 20:49, Stephen Frost sfr...@snowman.net wrote:
In the end, I may agree with you- the patch is a nice idea, but it needs
more to be a complete and working solution and providing something that
only gets people half-way there would result in developers hacking
things together
On 29 December 2012 21:24, Pavel Stehule pavel.steh...@gmail.com wrote:
can we remove CONSTRAINT_NAME from this patch? Minimally TABLE_SCHEMA,
TABLE_NAME and COLUMN_NAME works as expected.
CONSTRAINT_NAME can be implemented after constraints refactoring
This patch is almost completely
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
if (constraint_name == upc)
MessageBox(That is not a valid barcode.);
So they'll quickly realize that a lookup-table based on constraint name
would be useful, create it, and then have a primary key on it to make
sure that they don't
On 29 December 2012 22:57, Stephen Frost sfr...@snowman.net wrote:
So they'll quickly realize that a lookup-table based on constraint name
would be useful, create it, and then have a primary key on it to make
sure that they don't have any duplicates.
I don't find that terribly likely. There is
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
In order for the problem you describe to happen, the user would have
to ignore the warning in the documentation about constraint_name's
ability to uniquely identify something, and then have two constraints
in play at the same time with
On 30 December 2012 02:01, Stephen Frost sfr...@snowman.net wrote:
I really don't think what I sketched out or something similar would
happen. I do think it's incredibly frustrating as a user who is trying
to develop an application which behaves correctly to be given only half
the
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 30 December 2012 02:01, Stephen Frost sfr...@snowman.net wrote:
I really don't think what I sketched out or something similar would
happen. I do think it's incredibly frustrating as a user who is trying
to develop an application which
On 30 December 2012 03:32, Stephen Frost sfr...@snowman.net wrote:
Err. I intended to say I really don't think what I sketched out, or
something similar, would be that unlikely to happen, or something along
those lines. Apologies for the confusion.
Almost anything can be misused.
If you're
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 30 December 2012 03:32, Stephen Frost sfr...@snowman.net wrote:
Err. I intended to say I really don't think what I sketched out, or
something similar, would be that unlikely to happen, or something along
those lines. Apologies for the
2012/12/30 Stephen Frost sfr...@snowman.net:
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 30 December 2012 03:32, Stephen Frost sfr...@snowman.net wrote:
Err. I intended to say I really don't think what I sketched out, or
something similar, would be that unlikely to happen, or
Pavel, Peter,
To be honest, I haven't been following this thread at all, but I'm kind
of amazed that this patch seems to be progressing. I spent quite a bit
of time previously trying to change the CSV log structure to add a
single column and this patch is adding a whole slew of them. My prior
Hello
2012/12/28 Stephen Frost sfr...@snowman.net:
Pavel, Peter,
To be honest, I haven't been following this thread at all, but I'm kind
of amazed that this patch seems to be progressing. I spent quite a bit
of time previously trying to change the CSV log structure to add a
single column
Stephen Frost sfr...@snowman.net writes:
To be honest, I haven't been following this thread at all, but I'm kind
of amazed that this patch seems to be progressing. I spent quite a bit
of time previously trying to change the CSV log structure to add a
single column and this patch is adding a
On 28 December 2012 14:00, Stephen Frost sfr...@snowman.net wrote:
There are some additional concerns regarding the patch itself that I
have (do we really want to modify ereport() in this way? How can we
implement something which scales better than just adding more and more
parameters?) but I
On 28 December 2012 15:57, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that part's been agreed to at all; it seems entirely
possible that it'll get dropped if/when the patch gets committed.
I'm not convinced that having these fields in the log is worth
the compatibility hit of changing
On 28 December 2012 18:40, Pavel Stehule pavel.steh...@gmail.com wrote:
If
I understand you, we have a fields that has behave that you expected -
filename and funcname. And I have not used these fields for
application programming.
No, that's not what I mean. What I mean is that it seems
2012/12/28 Peter Geoghegan pe...@2ndquadrant.com:
On 28 December 2012 18:40, Pavel Stehule pavel.steh...@gmail.com wrote:
If
I understand you, we have a fields that has behave that you expected -
filename and funcname. And I have not used these fields for
application programming.
No, that's
On 28 December 2012 19:23, Pavel Stehule pavel.steh...@gmail.com wrote:
for this subject ANSI SQL is more relevant source or manual for DB2 or
Oracle. Design of Python and native PL languages are different. Python
can use complex nested structures. PL - PL/pgSQL or PL/PSM is designed
for work
2012/12/28 Peter Geoghegan pe...@2ndquadrant.com:
On 28 December 2012 19:23, Pavel Stehule pavel.steh...@gmail.com wrote:
for this subject ANSI SQL is more relevant source or manual for DB2 or
Oracle. Design of Python and native PL languages are different. Python
can use complex nested
On 12/10/12 4:23 PM, Peter Geoghegan wrote:
Well, this is an area that the standard doesn't have anything to say
about. The standard defines errcodes, but not what fields they make
available. I suppose you could say that the patch proposes that they
become a Postgres extension to the standard.
On 12/28/12 2:03 PM, Peter Geoghegan wrote:
No, that's not what I mean. What I mean is that it seems questionable
to want to do anything *within* an exception handler on the basis of
where an exception was raised from.
Isn't that the whole point of this patch? The only purpose of this
feature
On 28 December 2012 19:55, Pavel Stehule pavel.steh...@gmail.com wrote:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fdb2%2Frbafzmstgetdiag.htm
I'm unconvinced by this. First of all, it only applies to the GET
DIAGNOSTICS statement, and the only implementation that
On 12/28/12 2:03 PM, Peter Geoghegan wrote:
Are you aware of any popular programming language that provides this
kind of information? Can you tell in a well-principled way what
function a Python exception originated from, for example? These are
the built-in Python 2 exception classes:
On 28 December 2012 20:34, Peter Eisentraut pete...@gmx.net wrote:
Isn't that the whole point of this patch? The only purpose of this
feature is to make the exception information available in a
machine-readable way. That functionality has been requested many
times over the years.
Right, and
2012/12/28 Peter Geoghegan pe...@2ndquadrant.com:
On 28 December 2012 19:55, Pavel Stehule pavel.steh...@gmail.com wrote:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fdb2%2Frbafzmstgetdiag.htm
I'm unconvinced by this. First of all, it only applies to the GET
On 28 December 2012 20:40, Pavel Stehule pavel.steh...@gmail.com wrote:
It cannot to wait to GET DIAGNOSTICS request - because when GET
DIAGNOSTICS is called, then all unsupported info about exception is
lost, all used memory will be released.
I'm not suggesting that you do. I'm only
2012/12/28 Peter Geoghegan pe...@2ndquadrant.com:
On 28 December 2012 20:40, Pavel Stehule pavel.steh...@gmail.com wrote:
It cannot to wait to GET DIAGNOSTICS request - because when GET
DIAGNOSTICS is called, then all unsupported info about exception is
lost, all used memory will be released.
On 28 December 2012 20:40, Peter Eisentraut pete...@gmx.net wrote:
Sure, OSError has a filename attribute (which I'm sure is qualified by a
directory name if necessary), SyntaxError has filename, lineno, etc.
OSError.filename is essentially the equivalent of what is being proposed
here.
I
Peter Eisentraut pete...@gmx.net writes:
On 12/28/12 2:03 PM, Peter Geoghegan wrote:
None of the Python built-in exception types have this kind of
information available from fields or anything.
Sure, OSError has a filename attribute (which I'm sure is qualified by a
directory name if
2012/12/29 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net writes:
On 12/28/12 2:03 PM, Peter Geoghegan wrote:
None of the Python built-in exception types have this kind of
information available from fields or anything.
Sure, OSError has a filename attribute (which I'm sure is
On 11 December 2012 13:01, Pavel Stehule pavel.steh...@gmail.com wrote:
There are two basic aspects of design
* usability - we would to remove necessity of parsing error messages
for getting interesting data, it decrease dependency on current error
messages - then I am thinking so some
Hello
2012/12/10 Peter Geoghegan pe...@2ndquadrant.com:
So, I took a look at this, and made some more changes.
I have a hard time seeing the utility of some fields that were in this
patch, and so they have been removed from this revision.
Consider, for example:
+ constraint_table text,
Hello
2012/12/10 Peter Geoghegan pe...@2ndquadrant.com:
On 10 December 2012 20:52, David Johnston pol...@yahoo.com wrote:
Just skimming this topic but if these enhanced error fields are going to be
used by software, and we have 99% adherence to a standard, then my first
reaction is why not
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Peter Geoghegan
Sent: Monday, December 10, 2012 3:29 PM
To: Pavel Stehule
Cc: PostgreSQL Hackers; Alvaro Herrera; Tom Lane
Subject: Re: [HACKERS] enhanced error
On 10 December 2012 20:52, David Johnston pol...@yahoo.com wrote:
Just skimming this topic but if these enhanced error fields are going to be
used by software, and we have 99% adherence to a standard, then my first
reaction is why not just supply Not Applicable (or Not Available as
Peter Geoghegan escribió:
I think that we're both going to be busy next week, since we're both
attending pgconf.eu. For that reason, I would like to spend some time
tomorrow to get something in shape, that I can mark ready for
committer. I'd like to get this patch committed during this
On 24 October 2012 23:29, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Let me know if you think that that's a good idea.
I guess you didn't get around to it.
I did get some work on this done, which does change things somewhat.
In particular, I think that the need to have so many new fields
Peter Geoghegan escribió:
On 24 October 2012 23:29, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Let me know if you think that that's a good idea.
I guess you didn't get around to it.
I did get some work on this done, which does change things somewhat.
In particular, I think that
Hello
2012/10/20 Peter Geoghegan pe...@2ndquadrant.com:
I think that we're both going to be busy next week, since we're both
attending pgconf.eu. For that reason, I would like to spend some time
tomorrow to get something in shape, that I can mark ready for
committer. I'd like to get this
I think that we're both going to be busy next week, since we're both
attending pgconf.eu. For that reason, I would like to spend some time
tomorrow to get something in shape, that I can mark ready for
committer. I'd like to get this patch committed during this
commitfest. You are welcome to do
On 12 October 2012 20:27, Pavel Stehule pavel.steh...@gmail.com wrote:
I understand to your request, but I don't thing so this request is
100% valid. Check violation is good example. Constraint names are
optional in PostgreSQL - so we cannot require constraint_name. One
from first prototypes I
Hello
2012/10/11 Peter Geoghegan pe...@2ndquadrant.com:
On 10 October 2012 14:56, Pavel Stehule pavel.steh...@gmail.com wrote:
(eelog3.diff)
This looks better.
You need a better comment here:
+ * relerror.c
+ * relation error loging functions
+ *
I'm still not satisfied with
On 10 October 2012 14:56, Pavel Stehule pavel.steh...@gmail.com wrote:
(eelog3.diff)
This looks better.
You need a better comment here:
+ * relerror.c
+ * relation error loging functions
+ *
I'm still not satisfied with the lack of firm guarantees about what
errcodes one can assume
Hello Peter
here is updated patch, sorry for missing file
Regards
Pavel
2012/10/8 Peter Geoghegan pe...@2ndquadrant.com:
On 20 August 2012 14:09, Pavel Stehule pavel.steh...@gmail.com wrote:
(eelog-2012-08-20.diff)
This patch has the following reference to relerror.c:
***
1 - 100 of 132 matches
Mail list logo
