=?UTF-8?B?SmFuIEt1bmRyw6F0?= j...@flaska.net writes:
Attached is a second version of this patch which keeps the size of the
output at 64 characters per column (which is an arbitrary value defined
as a const int, which I hope matches your style). Longer values have
their last three characters
Tom Lane t...@sss.pgh.pa.us wrote:
I was wondering in particular whether it wouldn't be appropriate
to include the same errdetail in ExecConstraints's other check,
the one for null in not-null columns. Arguably a not-null check
is just a slightly optimized form of a CHECK constraint, and
On 11/10/11 00:48, José Arthur Benetasso Villanova wrote:
First, I couldn't apply it as in the email, even in REL9_0_STABLE: the
offset doesn't look right. Which commit are your repository in?
Hi Jose, thanks for looking at the patch. It's based on
b07b2bdc570cfbb39564c8a70783dbce1edcb3d6,
Hi José and Robert, thanks for your time and a review. Comments below.
On 11/10/11 03:47, Robert Haas wrote:
It does this already, without this patch. This patch is about CHECK
constraints, not UNIQUE ones.
That's right. This is how to check what the patch changes:
jkt= CREATE TABLE tbl
Hello
(And as a side note, I'm not really familiar with Postgres' internals,
so it took me roughly six hours to arrive to a working patch from the
very start. I'd therefore welcome pointers about the best way to achieve
that with Postgres' string stream interface.)
Hi José and Robert, thanks for your time and a review. Comments below.
On 11/10/11 03:47, Robert Haas wrote:
It does this already, without this patch. This patch is about CHECK
constraints, not UNIQUE ones.
That's right. This is how to check what the patch changes:
jkt= CREATE TABLE tbl
2011/11/10 Jan Kundrát j...@flaska.net:
On 11/10/11 03:47, Robert Haas wrote:
It does this already, without this patch. This patch is about CHECK
constraints, not UNIQUE ones.
That's right. This is how to check what the patch changes:
jkt= CREATE TABLE tbl (name TEXT PRIMARY KEY, a INTEGER
On 11/10/11 12:41, Dickson S. Guedes wrote:
jkt= UPDATE tbl SET a = -a;
ERROR: new row for relation tbl violates check constraint tbl_a_check
DETAIL: New row with data (x, -10) violates check constraint tbl_a_check.
The last line, the detailed error message, is added by the patch.
The
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát j...@flaska.net wrote:
That's an interesting thought. I suppose the same thing is an issue with
unique keys, but they tend to not be created over huge columns, so it
isn't really a problem, right?
Pretty much.
Would you object to a patch which
On 11/10/11 13:04, Robert Haas wrote:
Well, if we're going to try to emit some context here, I'd suggest
that we try to output only the columns implicated in the CHECK
constraint, rather than the whole tuple. I'm not sure whether
emitting only a certain amount of output (either total, or for
What I want to find in the end is something which tells me this row
causes the error. Unfortunately, as the new row of the table with the
constraint is not yet on disk, it doesn't really have its own ctid, and
therefore I cannot report that. (Which makes sense, obviously.)
Would an error with
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát j...@flaska.net wrote:
Would you object to a patch which outputs just the first 8kB of each
column? Having at least some form of context is very useful in my case.
Well, if we're going to try to emit some
On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát j...@flaska.net wrote:
Would you object to a patch which outputs just the first 8kB of each
column? Having at least some form of context
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, if we're going to try to emit some context here, I'd suggest
that we try to output only the columns implicated in the CHECK
On 11/10/11 16:05, Tom Lane wrote:
I agree with Jan that this is probably useful; I'm pretty sure there
have been requests for it before. We just have to make sure that the
length of the message stays in bounds.
One tip for keeping the length down: there is no value in repeating
Hi,
when I insert/update many rows at once using INSERT ... SELECT into a
table which has plenty of CHECK constraints, the error message that
Postgres returns has no indication of which row failed the constraint
check. The attached patch tries to provide information in a similar way
to how
2011/11/9 José Arthur Benetasso Villanova jose.art...@gmail.com:
postgres=# create table test1(id serial primary key, value text);
NOTICE: CREATE TABLE will create implicit sequence test1_id_seq for
serial column test1.id
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
17 matches
Mail list logo
