Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
>> You wouldn't be able to find errors in the semantics of xids for example, or
>> in the WAL logic that didn't cover some corner case. Or race conditions
>> between backends...
> Going into this, these were p
On Tue, 12 Oct 2004, Neil Conway wrote:
> On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
> > But it seems to me that most of the really hard bugs to find involve subtle
> > interactions between functions and the state of the database.
> >
> > You wouldn't be able to find errors in the semantics of
On Mon, 11 Oct 2004, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
> >> Most likely (and I for one will for sure resist any attempt to force
> >> global uniqueness on static names).
>
> > You're right that the issue can be avoided easily
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
>> Most likely (and I for one will for sure resist any attempt to force
>> global uniqueness on static names).
> You're right that the issue can be avoided easily enough, but what need
> is there _not_ to have g
On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
> But it seems to me that most of the really hard bugs to find involve subtle
> interactions between functions and the state of the database.
>
> You wouldn't be able to find errors in the semantics of xids for example, or
> in the WAL logic that didn
On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
> Most likely (and I for one will for sure resist any attempt to force
> global uniqueness on static names).
You're right that the issue can be avoided easily enough, but what need
is there _not_ to have globally unique function names?
-Neil
---
Neil Conway <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
> > 2. Won't dissolving away "static" cause naming conflicts?
>
> It might, yes. Those can be resolved, I think. I don't see a good reason why
> function names can't be unique across the source tree; at the very least, it
> means les
Neil Conway wrote:
3. Unit testing frameworks are best suited to component-based
architectures, ISTM. I'm not sure that one would fit Postgres very well.
Can you elaborate?
With objects that are relatively standalone, you can instantiate them
easily and plug them into a testing framework. The
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> 2. Won't dissolving away "static" cause naming conflicts?
Most likely (and I for one will for sure resist any attempt to force
global uniqueness on static names). It seems that that whole issue
is easily avoided though ... just #include the source file
Andrew Dunstan wrote:
2. Won't dissolving away "static" cause naming conflicts?
It might, yes. Those can be resolved, I think. I don't see a good reason
why function names can't be unique across the source tree; at the very
least, it means less irritation for anyone using tags.
3. Unit testing f
Neil Conway wrote:
[ apologies if this mail is poorly formatted, posted via webmail ]
Gavin Sherry said:
For the latest few weeks Neil and I have been discussing unit testing as
a means of testing Postgres more rigorously.
I should note that we've also been looking at some other ideas, inc
[ apologies if this mail is poorly formatted, posted via webmail ]
Gavin Sherry said:
> For the latest few weeks Neil and I have been discussing unit testing as
> a means of testing Postgres more rigorously.
I should note that we've also been looking at some other ideas, including
different appro
12 matches
Mail list logo
