Re: preserving forensic information when we freeze

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: preserving forensic information when we freeze
Дата
Msg-id 20131228022444.GW2543@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: preserving forensic information when we freeze  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: preserving forensic information when we freeze
Список pgsql-hackers
Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Dec 27, 2013 at 6:15 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > For my 2c, I tend to agree w/ Andres on this one.  I like the *idea* of
> > having a function instead, but, practically, it doesn't really work.
> > Perhaps if the 'function' approach was one-function-per-column and we
> > could remove the need for the function to take any arguments, but I'm
> > not sure we've really got something better than what we have now.
>
> I'm not sure what you mean by "doesn't work", because it clearly does
> work.  I've already posted a patch.  You may find it ugly, but that's
> not the same as not working.

I meant *practically*, it doesn't work.  By which, I mean, "it sucks" as
a solution. :)

> > Hindsight being what it is, perhaps we should have stuffed the system
> > columns into a complex type instead of having individual columns, but
> > I'm not sure changing that now would be worth the backwards
> > compatibility break (yes, I know they're system columns, but I've seen
> > more than one case of using ctid to break ties in otherwise identical
> > rows..).
>
> Well, if the consensus is in favor of adding more system columns,
> that's not my first choice, but I'm OK with it.  However, I wonder how
> we plan to name them.  If we add pg_infomask and pg_infomask2, it
> won't be consistent with the existing naming convention which doesn't
> include any kind of pg-prefix, but if we don't use such a prefix then
> every column we add further pollutes the namespace.

Yeah, I agree that it gets a bit ugly...  What would you think of doing
*both*?  Keep the existing system columns for backwards compatibility,
but then also have a complex 'pg_header' type which provides all of the
existing columns, as well as infomask && infomask2 ...?

I've not looked into any of the implementation complexity, but it might
give us a path to providing *just* the 'pg_header' (or whatever color we
end up making that bike shed...) complex type with all the system
columns available under it, maybe only using that in 10.0?
Thanks,
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "MauMau"
Дата:
Сообщение: Re: [bug fix] ECPG app crashes due to SIGBUS on SPARC Solaris
Следующее
От: David Rowley
Дата:
Сообщение: [PATCH] work_mem calculation possible overflow