From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jon Jensen <jon(at)endpoint(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: pg_get_constraintdef() doesn't always give an equal constraint |
Date: | 2015-03-30 15:00:37 |
Message-ID: | 20150330150037.GY3663@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Jon Jensen <jon(at)endpoint(dot)com> writes:
> > Well, as part of the standard regression test suite it's comparing stored
> > expected output with newly-generated output, like all the other tests. I
> > must be misunderstanding what you mean because nothing manual about that,
> > is there?
>
> My point is that the expected output has to be manually checked initially
> to see if it's right or not; and since it often doesn't look exactly like
> the original SQL, that checking is painful and not foolproof.
>
> It's interesting to consider something like the COPY_PARSE_PLAN_TREES
> #define, which inserts code into the backend to see whether copyfuncs.c
> and equalfuncs.c are sane or not. Running the regression tests with
> that turned on provides pretty thorough coverage of those modules.
Do we have any buildfarm members which are running with that? If not,
would anyone object to doing so?
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-03-30 15:02:31 | Re: pg_get_constraintdef() doesn't always give an equal constraint |
Previous Message | Kistler, Winnie C. | 2015-03-30 13:50:09 | Problem with date formatting and FM |