Re: BUG #14164: Postgres allow to insert more data into field than this field allow
От | David G. Johnston |
---|---|
Тема | Re: BUG #14164: Postgres allow to insert more data into field than this field allow |
Дата | |
Msg-id | CAKFQuwZvhOUNTiUa2VYfidFKPcibj7Jd6TmfhEsSAgcidn6d3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14164: Postgres allow to insert more data into field than this field allow (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #14164: Postgres allow to insert more data into field than this field allow
|
Список | pgsql-bugs |
On Mon, May 30, 2016 at 1:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > kes-kes@yandex.ru writes: > > Because of type of column of source and destination tables are equal > > postgres does not check actual data so very long data at text field of > mysql > > database is inserted into limited field at postgres DB. > > I would say this is a bug in mysql_fdw, not Postgres proper. In general > it's the responsibility of an FDW to ensure that data it passes back > meets the constraints of the foreign table declaration. > K>>=E2=80=8B 4) =E2=80=8BK>>=E2=80=8B INSERT INTO files2_102009 SELECT * FROM files2_mysql; =E2=80=8BI'm surprised that the definition of the object in the FROM clause= affects behavior in this manner... For the uninitiated while we do allow text type definitions to include length restrictions the underlying storage model is the same for any and all text variations you can legally describe (char, varchar, text, varchar(n)) though some special behaviors occur during input/output depending upon the type name and optional attribute. I'd be more inclined to play with this if it didn't require such a specific combination of technologies to readily reproduce. I'd at least like to understand the implications this would have on our system if it is allowed to stand. The specific situation I'm thinking of is a table that didn't require a toast but is now faced with a text value too large to fit onto a page. At some point in this SELECT->INSERT process there has to be a recognition that the data we are seeing is external and needs to be validated against the rules and assumptions of PostgreSQL. It's not our fault that mysql_fdw is broken but it is our fault that we allowed its brokenness to result is non-conforming persisted data. Either the SELECT should fail because a PostgreSQL varchar(255) cannot hold longer data (probably this) or the INSERT should fail so that at least the impact of the broken varchar is limited to an active query and doesn't make it onto disk. David J.
В списке pgsql-bugs по дате отправления: