Re: pg_dump exclusion switches and functions/types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump exclusion switches and functions/types
Дата
Msg-id 14107.1160521319@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump exclusion switches and functions/types  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers
"Greg Sabino Mullane" <greg@turnstep.com> writes:
>> Sure, but the question is whether that incremental gain in capability
>> is worth the extra logical complexity.  I'm inclined to think that many
>> more users would get burned by the complexity than would have use for
>> it.

> I disagree - we lose a lot of flexibility by taking out the ordering,

We lose some flexibility, but it's not clear to me that it's so
essential as all that.  Even the restricted patch is tremendously
more flexible than pg_dump has ever been, and I just don't see the
argument that there's a market demand for doing more at the cost
of clarity.

> I'm also not sure why the regex
> should be changed to something even more non-standard than the current
> POSIX ones. Finally, I'm surprised at the apparent willingness at this
> point to shatter backwards-compatibility with previous -t scripts, as
> this was an option I raised early on but met strong resistance, thus
> the current compromise of allowing existing scripts to run unaltered,
> while adding in the ability to do some regular expressions.

That's a fair point, but the way that the patch was preserving exact
backward compatibility was by making it a discontinuous corner case,
which is a decision I think we'd regret in the long run.  Andrew was
already suggesting upthread that we drop the anchoring (and lose
compatibility to a much greater extent than what this does) in order
to make the behavior more self-consistent.  Also, insisting on straight
regexps amounts to failing to learn from experience: before 7.3 the psql
\d commands used patterns that *were* straight regexps, and that just
did not work all that conveniently.

> The regex stuff was discussed in January, and the patch submitted in
> July, so it seems a little rushed to be changing the underlying behavior
> so quickly right now

Well, the problem is that once we ship 8.2 we'll be stuck with whatever
behavior we've defined --- it's unlikely that it'd be worth the pain of
another round of incompatibility in order to make small adjustments.
So we'd better get it right the first time.  I do apologize for not
having reviewed this patch more closely earlier, but I've been a tad
busy...
        regards, tom lane


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

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: Index Tuning Features
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: 8.2beta1 does not compile for me on Solaris 10