Ken Tanzer writes:
>>> I dug in the archives and came across a crude POC hack here:
>>> https://www.postgresql.org/message-id/21693.1478376...@sss.pgh.pa.us
>> For that matter, it's not totally
>> clear what would constitute an improvement --- what do you wish it would
>> show you, exactly?
> It
>
> I dug in the archives and came across a crude POC hack here:
>
> https://www.postgresql.org/message-id/21693.1478376...@sss.pgh.pa.us
>
> At the time I didn't want to pursue it further because of Andres'
> pending work on redoing expression execution, but that's landed now.
>
>
Dang. +1 for that.
Not that you hadn’t thought of it, and not that it’s actually a viable solution
in a jiffy, but switch that mess to JSONB and your problems are over.
"David G. Johnston" writes:
> I seem to recall a discussion a few years back but cannot find it searching
> online. The one post I did find was from 6 years ago and I was the only
> respondent and basically said the same or less than I am here.
I dug in the archives and came across a crude POC h
On Fri, Feb 16, 2018 at 5:30 PM, Ken Tanzer wrote:
>
> That doesn't matter much in a simple example like that, but the example
> below is currently making me wish PG was just a little bit more specific.
> Is there much chance of this changing in future releases?
>
>
I'm not holding my breath...
Ken Tanzer writes:
> Hi. If you try to assign a too-long string to a field, Postgresql will say
> so, but won't tell you which value/field is causing the problem:
> CREATE TEMP TABLE foo (a VARCHAR(2));
> INSERT INTO foo VALUES ('ABC');
> CREATE TABLE
> ERROR: value too long for type character v
Hi. If you try to assign a too-long string to a field, Postgresql will say
so, but won't tell you which value/field is causing the problem:
CREATE TEMP TABLE foo (a VARCHAR(2));
INSERT INTO foo VALUES ('ABC');
CREATE TABLE
ERROR: value too long for type character varying(2)
That doesn't matter
