Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Well if we are going to continue to support money (which I am against)
> > we should support the casting to numeric as that is by far a more
> > common implementation of money and we will have mixed environments.
>
> So, you don't
Since Simon seems intent on hacking something in there, here is a patch
that I think is actually sane for improving operator lookup speed.
This patch caches all lookups, exact or ambiguous (since even the exact
ones require multiple cache searches in common cases); and behaves sanely
in the presenc
Per recent discussion, plpgsql's handling of block labels is not very
desirable: it will recognize unqualified identifiers as being block
labels even in contexts where a block label is illegal, and it will
prefer a match involving a block label over one that doesn't, even
when the second match is i
Tom Lane wrote:
Ah. The reason this works in VPATH mode is that setup of the build tree
duplicated all subdirectories of the source tree, so ./input/ should
exist iff $srcdir/input/ does. I agree it's a bit ugly though; it'd
be better to stat what we really plan to read.
Maybe push the stat op
Jorgen Austvik <[EMAIL PROTECTED]> writes:
> But if we have set srcdir, the directory we are stat'ing, is not the
> same directory that we are reading the files from:
Ah. The reason this works in VPATH mode is that setup of the build tree
duplicated all subdirectories of the source tree, so ./in
Tom Lane wrote:
Jorgen Austvik <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Actually, it looks to me like the patch is wrong specifically because
it does not do the right thing in the VPATH case.
Are you thinking about "failing if the folders are missing" as "not the
right thing in the VPATH
Jorgen Austvik <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, it looks to me like the patch is wrong specifically because
>> it does not do the right thing in the VPATH case.
> Are you thinking about "failing if the folders are missing" as "not the
> right thing in the VPATH case", or
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
I didn't check the rest of the patch, but did you verify that it still
works in VPATH builds?
Actually, it looks to me like the patch is wrong specifically because
it does not do the right thing in the VPATH case.
Are you thinking ab
Alvaro Herrera wrote:
Jorgen Austvik - Sun Norway wrote:
This patch will also make pg_regress fail if the directories are
missing, instead of silently ignoring the missing directories. If you
think this fail-fast behavior is undesirable, I can create a patch
that just ignores the files (todays
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I didn't check the rest of the patch, but did you verify that it still
> works in VPATH builds?
Actually, it looks to me like the patch is wrong specifically because
it does not do the right thing in the VPATH case.
regards, tom
Jorgen Austvik - Sun Norway wrote:
> This patch will also make pg_regress fail if the directories are
> missing, instead of silently ignoring the missing directories. If you
> think this fail-fast behavior is undesirable, I can create a patch
> that just ignores the files (todays behavior), or ign
Hi,
I think I have found a small problem in pg_regress.
In convert_sourcefiles() it stats directories based on the current
working directory, but in convert_sourcefiles_in() it reads files based
in srcdir or abs_builddir.
The attached patch changes the behavior of pg_regress, so that it stat
12 matches
Mail list logo
