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
--
Sen
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 +
2013/1/29 Peter Geoghegan :
> On 29 January 2013 17:05, Pavel Stehule 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
>
> R
On 29 January 2013 17:05, Pavel Stehule 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 really any use to yo
2013/1/28 Peter Geoghegan :
> On 28 January 2013 21:33, Peter Eisentraut 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
2013/1/27 Tom Lane :
> Peter Geoghegan writes:
>> On 26 January 2013 22:36, Tom Lane 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 really pe
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(),
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 +
On 28 January 2013 21:33, Peter Eisentraut 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
> while exec
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,
2013/1/28 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/28 Tom Lane :
>>> ... 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 domain
Pavel Stehule writes:
> 2013/1/28 Tom Lane :
>> ... 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 domain schema, but we'd need a new
2013/1/28 Tom Lane :
> 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 th
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 CONSTRAINT_SCHEMA+CONSTRAINT_
Peter Geoghegan writes:
> On 27 January 2013 18:57, Tom Lane 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 developers' face when he's
>> copying-and
Peter Geoghegan writes:
> On 26 January 2013 22:36, Tom Lane 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 really per spec?
>> I'd have sort of
On 27 January 2013 18:57, Tom Lane wrote:
> Peter Geoghegan 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 standard instituted, so that in
>> future c
Peter Geoghegan writes:
> On 26 January 2013 22:36, Tom Lane 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 purposes here. Guarantee may have
> been too
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
> f
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
On 26 January 2013 22:36, Tom Lane 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 given SQLSTATE.
Peter Geoghegan 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 hacker, but I thin
Peter Geoghegan 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 of having a well-pr
On 13 January 2013 06:13, Pavel Stehule 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 of the time and
Hello
2012/12/29 Stephen Frost :
> * 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
2013/1/5 Peter Geoghegan :
> On 5 January 2013 16:56, Pavel Stehule 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
>>> sho
On 5 January 2013 16:56, Pavel Stehule 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 there agreeme
2013/1/4 Peter Geoghegan :
> On 4 January 2013 18:07, Tom Lane 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
>>
Hello
2013/1/4 Robert Haas :
> On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan
> 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
>> fee
On 4 January 2013 17:10, Robert Haas 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 to populate those
On 4 January 2013 18:07, Tom Lane 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 isn't in the cur
"anara...@anarazel.de" writes:
> Robert Haas 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
>> regex. And then do just wha
Robert Haas schrieb:
>On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
> 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 f
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan 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 feature. Why should the
On Fri, Dec 28, 2012 at 1:21 PM, Peter Geoghegan 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 that we don't need
2012/12/30 Stephen Frost :
> * 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,
* 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 alw
2012/12/30 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> On 30 December 2012 03:32, Stephen Frost 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
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 30 December 2012 03:32, Stephen Frost 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.
>
On 30 December 2012 03:32, Stephen Frost 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 going to insis
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 30 December 2012 02:01, Stephen Frost 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 correct
On 30 December 2012 02:01, Stephen Frost 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 information.
I don't know
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 wit
On 29 December 2012 22:57, Stephen Frost 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 nothing broken
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 do
On 29 December 2012 21:24, Pavel Stehule 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 pointless without a CONSTRA
On 29 December 2012 20:49, Stephen Frost 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 which will qui
2012/12/29 Stephen Frost :
> * 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
* 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 :
> * 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*.
>
* 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
On 29 December 2012 19:56, Stephen Frost 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 tryin
2012/12/29 Stephen Frost :
> * 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
* 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? U
2012/12/29 Stephen Frost :
> * 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
>> almo
* 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 constraint_s
2012/12/29 Peter Geoghegan :
> On 29 December 2012 18:37, Stephen Frost 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,
On 29 December 2012 18:37, Stephen Frost 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 since a constraint i
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 k
2012/12/29 Peter Geoghegan :
> On 29 December 2012 17:43, Stephen Frost 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 r
On 29 December 2012 17:43, Stephen Frost 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 which doesn't c
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 28 December 2012 15:57, Tom Lane 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 wo
2012/12/29 Tom Lane :
> Peter Geoghegan writes:
>> On 29 December 2012 05:04, Pavel Stehule 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 would
2012/12/29 Peter Geoghegan :
> On 29 December 2012 05:04, Pavel Stehule 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
>>
Peter Geoghegan writes:
> On 29 December 2012 05:04, Pavel Stehule 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 would provide only an utterly
>>>
On 29 December 2012 05:04, Pavel Stehule 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 exception, when it was rai
2012/12/29 Tom Lane :
> Peter Eisentraut 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
>> dire
Peter Eisentraut 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 necessary), Synt
On 28 December 2012 20:40, Peter Eisentraut 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 disagree. Tha
2012/12/28 Peter Geoghegan :
> On 28 December 2012 20:40, Pavel Stehule 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'
On 28 December 2012 20:40, Pavel Stehule 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 suggesting that the two are
no
2012/12/28 Peter Geoghegan :
> On 28 December 2012 19:55, Pavel Stehule 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 implement
On 28 December 2012 20:34, Peter Eisentraut 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 I agree t
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 19:55, Pavel Stehule 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 actually
currently uses th
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
featu
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 standa
2012/12/28 Peter Geoghegan :
> On 28 December 2012 19:23, Pavel Stehule 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 design
On 28 December 2012 19:23, Pavel Stehule 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 with simply scalar t
2012/12/28 Peter Geoghegan :
> On 28 December 2012 18:40, Pavel Stehule 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 t
On 28 December 2012 18:40, Pavel Stehule 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 questionable
to want to d
On 28 December 2012 15:57, Tom Lane 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 the CSV column se
On 28 December 2012 14:00, Stephen Frost 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 think we need
Stephen Frost 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 whole slew of th
Hello
2012/12/28 Stephen Frost :
> 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
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
pa
On 11 December 2012 13:01, Pavel Stehule 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 informations about trigge
Hello
2012/12/10 Peter Geoghegan :
> On 10 December 2012 20:52, David Johnston 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 "" (or "" as
>> appro
Hello
2012/12/10 Peter Geoghegan :
> 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,
> + constrai
On 10 December 2012 20:52, David Johnston 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 "" (or "" as
> appropriate) instead of suppressing the field a
> -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: R
Peter Geoghegan escribió:
> On 24 October 2012 23:29, Alvaro Herrera 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 h
On 24 October 2012 23:29, Alvaro Herrera 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 is
questionable, an
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
Hello
2012/10/20 Peter Geoghegan :
> 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 duri
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 th
On 12 October 2012 20:27, Pavel Stehule 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 used generated na
Hello
2012/10/11 Peter Geoghegan :
> On 10 October 2012 14:56, Pavel Stehule 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
On 10 October 2012 14:56, Pavel Stehule 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 these fields will be avai
Hello Peter
here is updated patch, sorry for missing file
Regards
Pavel
2012/10/8 Peter Geoghegan :
> On 20 August 2012 14:09, Pavel Stehule wrote:
>> (eelog-2012-08-20.diff)
>
> This patch has the following reference to relerror.c:
>
> """
>
> *** a/src/include/utils/rel.h
> --- b/src/inc
1 - 100 of 132 matches
Mail list logo
