Robert Haas <robertmhaas@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