Re: 2020-02-13 Press Release Draft

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: 2020-02-13 Press Release Draft
Дата
Msg-id 9f3635ca-2f41-621b-8abb-7c7f02a4c23a@postgresql.org
обсуждение исходный текст
Ответ на Re: 2020-02-13 Press Release Draft  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 2/10/20 12:23 PM, Alvaro Herrera wrote:
> On 2020-Feb-10, Jonathan S. Katz wrote:
>
>> * Several figures for GSSAPI support, including having libpq accept all
>> GSS-related connection parameters even if the GSSAPI code is not compiled in.
>
> "figures"?

"figures" I have a typo ;) Fixed to "fixes"

>
>> If you had previously executed `TRUNCATE .. CASCADE` on a sub-partition of a
>> partitioned table, and the partitioned table has a foreign-key reference from
>> another table, you will have to run the `TRUNCATE` on the other table as well.
>> The issue that caused this is fixed in this release, but you will have to
>> perform this step to ensure all of your data is cleaned up.
>
> I'm unsure about the "will" in the "you will have to run the TRUNCATE".
> If the table is truncated then reloading, then the truncation might be
> optional.  I would change the "will" to "may".

Changed. And...

> At the same time I
> wonder if it would make sense to provide a query that would return any
> rows violating such constraints; if empty then there's no need to
> truncate.  On the other hand, if not empty, perhaps we can suggest to
> delete just those rows rather than truncating everything.  Perhaps we
> can quote ri_triggers.c's RI_Initial_Check,
>
>     /*----------
>      * The query string built is:
>      *  SELECT fk.keycols FROM [ONLY] relname fk
>      *   LEFT OUTER JOIN [ONLY] pkrelname pk
>      *   ON (pk.pkkeycol1=fk.keycol1 [AND ...])
>      *   WHERE pk.pkkeycol1 IS NULL AND
>      * For MATCH SIMPLE:
>      *   (fk.keycol1 IS NOT NULL [AND ...])
>      * For MATCH FULL:
>      *   (fk.keycol1 IS NOT NULL [OR ...])
>      *
>      * We attach COLLATE clauses to the operators when comparing columns
>      * that have different collations.
>      *----------
>      */

...yeah, I like that approach, especially if it's "may" instead of
"will" -- we should give our users the tools to determine if they have
to do anything. Should we just give the base base?

    SELECT
        fk.keycol
    FROM
        relname fk
        LEFT OUTER JOIN pkrelname pk ON pk.pkkeycol = fk.keycol
    WHERE
        pk.pkkeycol IS NULL
        AND fk.keycol IS NOT NULL;

RE TRUNCATE vs. DELETE, we should present the option ("TRUNCATE" is the
easiest route, but you may opt to "DELETE" instead due to having
replaced the data)

Thanks,

Jonathan


Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Yet another vectorized engine
Следующее
От: Luís Roberto Weck
Дата:
Сообщение: Re: 2020-02-13 Press Release Draft