On Mon, Feb 06, 2006 at 05:08:38PM -0500, Alon Goldshuv wrote:
The proposal is neat, however, I am not too
excited about handling errors in such high granularity, as far as the user
is concerned. I am more on the same line with Tom Lane's statement in
Simon's thread (Practical error logging
On Sun, Feb 05, 2006 at 07:14:49PM -0800, Stephan Szabo wrote:
On Sun, 5 Feb 2006, James William Pye wrote:
However, constraints referenced in an UNLESS clause that are deferred, in
any
fashion, should probably be immediated within the context of the command.
Perhaps a WARNING or NOTICE
James,
Are you sure that a new type of constraint is the way to go for this?
It doesn't solve our issues in the data warehousing space. The spec we
started with for Error-tolerant COPY is:
1) It must be able to handle parsing errors (i.e. bad char set);
2) It must be able to handle
On Mon, 6 Feb 2006, Josh Berkus wrote:
Are you sure that a new type of constraint is the way to go for this?
It doesn't solve our issues in the data warehousing space. The spec we
started with for Error-tolerant COPY is:
1) It must be able to handle parsing errors (i.e. bad char set);
2)
On Mon, 6 Feb 2006, James William Pye wrote:
On Sun, Feb 05, 2006 at 07:14:49PM -0800, Stephan Szabo wrote:
On Sun, 5 Feb 2006, James William Pye wrote:
However, constraints referenced in an UNLESS clause that are deferred, in
any
fashion, should probably be immediated within the
Alon Goldshuv on Bizgres has been working on this as well. Maybe you
could collaborate? Alon?
I would love to collaborate. The proposal is neat, however, I am not too
excited about handling errors in such high granularity, as far as the user
is concerned. I am more on the same line with Tom
On Mon, Feb 06, 2006 at 11:03:06AM -0800, Josh Berkus wrote:
Are you sure that a new type of constraint is the way to go for this?
[Thinking that you are referring to the new constraint mode that I was
confusingly referring to...]
Well, it really wouldn't be new. It's just labeling what we do
James,
The difficulty of my implementation comes from the position that I don't
think the current implementation of UNIQUE constraints is ideal. It is
hidden inside nbtree, which, while convenient, is not likely to be the
best place for it.
Agreed; one of the things that's been on the TODO
James,
I am seeking, as many others are or have, to improve the performance on bulk
loads to live systems where constraint violations may occur and filtering can
be done more efficiently within the backend.
Primarily, I'm concerned with UNIQUE violations. However, I think tackling the
general
Folks,
The subject of this letter is referring to giving INSERT and COPY FROM STDIN
the ability to alter the destination of rows that violate any constraints named
in a user specified set.
BTW, just in case anyone thinks that James is not addressing a real and
widespread problem, Joe Conway
On Fri, 3 Feb 2006, James William Pye wrote:
Despite the fact that my experimental patch uses error trapping, that is *not*
what I have in mind for the implementation. I do not want to trap errors upon
insert or copy from. Rather, I wish to implement functionality that would
allow
On Sun, Feb 05, 2006 at 02:08:12PM -0800, Stephan Szabo wrote:
Have you considered how this might work with spec-compliant constraint
timing?
I haven't gone so far as to look into the spec, yet. [Noise of rustling papers]
However, constraints referenced in an UNLESS clause that are deferred,
On Sun, 5 Feb 2006, James William Pye wrote:
On Sun, Feb 05, 2006 at 02:08:12PM -0800, Stephan Szabo wrote:
Have you considered how this might work with spec-compliant constraint
timing?
I haven't gone so far as to look into the spec, yet. [Noise of rustling
papers]
However,
13 matches
Mail list logo
