Re: ASCII Backup mit korrekter Reihenfolge von Objekten? (Was: Backup lässt Daten der Tabelle "times" weg)

Am 09.07.22 um 05:47 schrieb Andreas Kretschmer:
> On 9 July 2022 05:36:54 CEST, Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> wrote:
>> On 8 July 2022 22:14:20 CEST, Andreas Tille <tille(at)debian(dot)org> wrote:
>>> Am Fri, Jul 08, 2022 at 04:20:46PM +0200 schrieb Andreas Tille:
>>>>> Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.
>>>> Die Sache ist so simpel. Da gibt's nur eine Datenbank.
>>> Ich glaube das Problem liegt anders - ich habe offensichtlich in der Zahl
>>> meiner Versuche die Backups verwechselt. Da wo die Daten fehlen, waren
>>> tatsächlich die Tabellen leer und das lag an einem Fehler im restore. Ich
>>> habe das reine Textbackup gemacht, um die Daten auch menschenlesbar zu
>>> behalten. Beim Restore kam
>>>
>>>
>>> FEHLER: Relation »streckeproperties« existiert nicht
>>> ZEILE 1: SELECT sort FROM StreckeProperties WHERE sort =...
>>> ^
>>> ANFRAGE: SELECT sort FROM StreckeProperties WHERE sort = $1
>>> KONTEXT: PL/pgSQL-Funktion public.test_property(integer) Zeile 5 bei SQL-Anweisung
>>>
>>>
>>> was daran liegt, dass die Tabelle StreckeProperties erst nach der Funktion
>>>
>>> CREATE FUNCTION public.test_property(integer) RETURNS boolean
>>> LANGUAGE plpgsql
>>> AS $_$
>>> Declare
>>> Success varchar ;
>>> BEGIN
>>> SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
>>> IF NOT FOUND THEN
>>> RETURN 'f' ;
>>> ELSE
>>> RETURN 't' ;
>>> END IF ;
>>> END; $_$;
>>>
>>> im Backup auftaucht. In times wird test_property benutzt - darum bleibt
>>> die Tabelle leer. Soweit ich mich erinnere ist in solchen Fällen das
>>> einfache
>>>
>>> pg_dump datenbank
>>>
>>> nicht mehr das Mittel der Wahl. Gibt es eine Möglichkeit, einen
>>> ASCII-Dump zu bekommen, bei dem die Relationen für einen korrekten
>>> Import abgelegt werden?
>>>
>>> Viele Grüße
>>>
>>> Andreas.
>>>
>> Die Zeiten, wo im Dump eine falsche Reihenfolge von Objekten zu Fehlern führten, sind ca. seit 10 Versionen oder mehr vorbei. Deine Funktion wird übrigens beim Restore weder ausgeführt noch compiliert oder so, daher kann das auch nicht sein. Du kannst eine Funktion auf eine nicht existente Tabelle ohne Probleme definieren, der Fehler käme erst beim ausführen.
>>
>> Was mich eher irritiert ist das 'sort', das ist ein reserviertes Wort. Das schaue mir später noch mal an ..
>>
> Schmarrn, sort ist nicht reserviert. Es fehlt Kaffee ...

So, mal nachvollzogen:

postgres=# CREATE FUNCTION public.test_property(integer) RETURNS boolean
    LANGUAGE plpgsql
    AS $_$
    Declare
    Success varchar ;
    BEGIN
      SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
      IF NOT FOUND THEN
        RETURN 'f' ;
      ELSE
        RETURN 't' ;
      END IF ;
    END; $_$;
CREATE FUNCTION
postgres=# SELECT              sort FROM StreckeProperties WHERE sort= 1;
ERROR:  relation "streckeproperties" does not exist
LINE 1: SELECT              sort FROM StreckeProperties WHERE sort= ...
                                      ^
postgres=#

Wie gesagt, erstellen kann man die Funktion auch dann, wenn die Tabelle
nicht existiert, der Fehler kommt erst beim Aufruf - und beim Einspielen
des Dumps erfolgt kein Aufruf dieser Funktion.

Du hast da übrigens ein Typenproblem: die Funktion erwartet einen
INT-Parameter, dann ein select sort ... where sort = $1.
Das sollte dann also einen INT liefern, speicherst ihn aber in einem
varchar.

Aber mit Deinem Problem hat das alles nichts zu tun ...

--
Andreas Kretschmer
Technical Account Manager (TAM)
www.enterprisedb.com