On Fri, 23 Nov 2007 15:59:29 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I also removed a ssymbol test because ssymbol will never be \0 based on
> the code. Also, what does this do:
>
> if (buf[LAST_DIGIT] == ',')
> buf[LAST_DIGIT] = buf[LAST_PAREN];
Good question.
Patch applied. I will email on this LAST_DIGIT issue separately.
---
Bruce Momjian wrote:
> In looking at the use of the thousands separator in formatting.c and
> psql/print.c, I now see similar problems with the MONEY type
D'Arcy J.M. Cain wrote:
> On Fri, 23 Nov 2007 15:59:29 -0500 (EST)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I also removed a ssymbol test because ssymbol will never be \0 based on
> > the code. Also, what does this do:
> >
> > if (buf[LAST_DIGIT] == ',')
> > buf[LAST_DIGIT]
On Sat, 24 Nov 2007 11:27:38 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I am confused about two other items with MONEY. First, why can't
> anything but a string be cast to this type?
>
> test=> select 871234872319489323::money;
> ERROR: cannot cast type bigint to money
>
Interesting. I was able to reproduce this with just pg_dump -c (clear).
We _could_ move the SET search_path out of that loop but that isn't the
right solution. _printTocEntry() already has the _selectOutputSchema()
call we need. I have no idea what object might need the
_selectOutputSchema() t
On Sat, 24 Nov 2007 11:27:38 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> And second, why are there no regression tests for MONEY. I see it used
> only once in the rules test.
I will be committing some regression tests as soon as I finish testing.
--
D'Arcy J.M. Cain <[EMAIL PROTECTED
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The correct solution is to reset AH->currSchema if we we dropped a
> schema.
No it isn't. This is an ugly, brute-force, misleadingly commented fix.
For one thing, why reset currSchema if it doesn't match the schema
we dropped? And what if we only drop
Tom Lane wrote:
> The fact that schema ss might not exist is one of the scenarios that
> we need to qualify the primary name in the DROP to protect against.
> It's possible say that "complex" would get mis-resolved as some other
> type "complex" in some other schema, but it doesn't matter since the
The attached proposed patch addresses the recent gripe that there is no
way for UNION (or related constructs) to return a domain type, because
select_common_type() always smashes all its inputs to base types:
http://archives.postgresql.org/pgsql-performance/2007-11/msg00278.php
The minimum-impact
