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
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
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 n
> 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 L
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" w
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);
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 constra
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
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,
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 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
> alte
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
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 c
Greets folks, [YABLP: Yet Another Bulk Loading Proposal]
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.
I am seeking, as many others are or have, to improve the p
14 matches
Mail list logo