Robert Haas <robertmh...@gmail.com> wrote: > So maybe instead of trying to cobble together a set of catalog > contents that we can use for decoding any tuple whatsoever, we > should instead divide the world into well-behaved types and > poorly-behaved types. Well-behaved types are those that can be > interpreted without the catalogs, provided that you know what type > it is. Poorly-behaved types (records, enums) are those where you > can't. For well-behaved types, we only need a small amount of > additional information in WAL to identify which types we're trying > to decode (not the type OID, which might fail in the presence of > nasty catalog hacks, but something more universal, like a UUID > that means "this is text", or something that identifies the C > entrypoint). And then maybe we handle poorly-behaved types by > pushing some of the work into the foreground task that's > generating the WAL: in the worst case, the process logs a record > before each insert/update/delete containing the text > representation of any values that are going to be hard to decode. > In some cases (e.g. records all of whose constituent fields are > well-behaved types) we could instead log enough additional > information about the type to permit blind decoding. What about matching those values up to the correct table name and the respective columns names? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
