On Aug 26, 2010, at 9:05 AM, Tom Lane wrote:
> On reflection, I think that the current system design for this is
> predicated on the theory that RECORDs really are all the same type, and
> the executor had better be prepared to cope with a series of RECORDs
> that have different tupdescs, or throw
I wrote:
> The issue seems to be that given a construct like
> ARRAY[
> ROW('1.2.2'::semver, '='::text, '1.2.2'::semver),
> ROW('1.2.23', '=', '1.2.23')
> ]
> the parser is satisfied upon finding that all the array elements are
> of type RECORD. It doesn'
On Tue, Aug 24, 2010 at 12:27 PM, Tom Lane wrote:
> This is a crash in released branches, so we have to have a
> back-patchable fix. Anything that gets out from under the typmod issue
> isn't going to be back-patchable.
I nominate that comment for "understatement of the year".
--
Robert Haas
E
Robert Haas writes:
> On Tue, Aug 24, 2010 at 11:32 AM, Tom Lane wrote:
>> I think it wouldn't take too much code to defend against this in
>> transformArrayExpr, but I'm a tad worried about whether there are
>> similar cases elsewhere. The generic problem is that we suppose that
>> different va
On Tue, Aug 24, 2010 at 11:32 AM, Tom Lane wrote:
> I think it wouldn't take too much code to defend against this in
> transformArrayExpr, but I'm a tad worried about whether there are
> similar cases elsewhere. The generic problem is that we suppose that
> different values are compatible if they
"David E. Wheeler" writes:
> On Aug 24, 2010, at 7:05 AM, Tom Lane wrote:
>> I get a core dump on that one ... looking ...
> Well I'm glad I reported it, then.
The issue seems to be that given a construct like
ARRAY[
ROW('1.2.2'::semver, '='::text, '1.2.2'::semver),
On Aug 24, 2010, at 7:05 AM, Tom Lane wrote:
> You could do it like this:
>
>SELECT cmp_ok(lv, op, rv) FROM unnest(ARRAY[
>ROW('1.2.2', '=', '1.2.2'),
>ROW('1.2.23', '=', '1.2.23')
>]::vcmp[]);
Oh, duh. :-)
>> psql:t/types.pg:205: ERROR: invalid memory alloc request si
On Aug 23, 2010, at 11:24 PM, Joe Conway wrote:
> Maybe something like this?
>
> select cmp_ok(a,b,c)
> from
> (
>values('1.2.2'::varchar, '='::text, '1.2.2'::varchar),
> ('1.2.23', '=', '1.2.23'),
> ('1.2.42', '=', '1.2.32')
> ) as ss(a, b, c);
> cmp_ok
>
> t
> t
"David E. Wheeler" writes:
> I've been trying to come up with a simpler way to iterate over a series of
> values in pgTAP tests than by creating a table, inserting rows, and then
> selecting from the table. The best I've come up with so far is:
> CREATE TYPE vcmp AS ( lv semver, op text, rv
On 08/23/2010 08:33 PM, David E. Wheeler wrote:
> I've been trying to come up with a simpler way to iterate over a
> series of values in pgTAP tests than by creating a table, inserting
> rows, and then selecting from the table. The best I've come up with
> so far is:
> Aside from that, might the
Hackers,
I've been trying to come up with a simpler way to iterate over a series of
values in pgTAP tests than by creating a table, inserting rows, and then
selecting from the table. The best I've come up with so far is:
CREATE TYPE vcmp AS ( lv semver, op text, rv semver);
SELECT cmp_
11 matches
Mail list logo
