drop + create v transakcii

[Michal Páleník]

ahojte

snažím sa v rámci transakcie nahradiť tabuľku inou (drop+create). toto
ale zlyhá, lebo tabuľka je súčasťou view. našiel som zopár stránok kde
vcelku vysvetľujú prečo drop ide kvázi mimo transakcie, ale všetky sú
veľa rokov staré (postgres 9*). predpokladám, že dôvody stále platia.

dáta prehadzuje z backendového serveru, kde ich zopár hodín ráta. viem
to zmeniť na truncate+copy ale občasne mením stĺpce a drop+create je
blbovzdornejšie.

(vlastne neviem akú mám otázku, len či to je naozaj tak)

skrátený sql, ktorý zlyhá na drop table:

create table tmp_dd1 (id int);
create view tmp_dd2 as select * from tmp_dd1;

begin;
drop table tmp_dd1;
-- cannot drop table tmp_dd1 because other objects depend on it
create table tmp_dd1 (id int);
commit;





--
michal palenik
www.freemap.sk
www.oma.sk

[Pavel Stehule]

út 13. 7. 2021 v 14:46 odesílatel Michal Páleník <michal....@freemap.sk> napsal:

cascade nepomuze?

Pavel

--
michal palenik
www.freemap.sk
www.oma.sk

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/YO2LD2pYY7IFuOxW%40tanicka.iz.sk.

[Petr Boháč]

Ahoj,

Jelikoz mam podezreni, ze to chces pouzivat opakovane, tak bych doporucil misto DROP ... CASCADE pridat explicitni DROP toho view. V budoucnu to usetri prekvapeni, ze by to droplo neco dalsiho s cim tento script nepocita.

Petr

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB-U_4U7tqxp%2BGW6mhJEHFNdGN%3DujVgJTiuKY-0PTAX%3DA%40mail.gmail.com.

[Pavel Stehule]

út 13. 7. 2021 v 17:31 odesílatel Petr Boháč <bohy...@gmail.com> napsal:

Ahoj,

Jelikoz mam podezreni, ze to chces pouzivat opakovane, tak bych doporucil misto DROP ... CASCADE pridat explicitni DROP toho view. V budoucnu to usetri prekvapeni, ze by to droplo neco dalsiho s cim tento script nepocita.

juju DROP CASCADE je tak trochu ruska ruleta :-)

Pavel

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAJj4Mw4ThdVhAEHFKBtDf_Pei_DefQVRW69W3htAHtWo_iZqiw%40mail.gmail.com.

[Michal Páleník]

On Tue, Jul 13, 2021 at 02:48:22PM +0200, Pavel Stehule wrote:
> út 13. 7. 2021 v 14:46 odesílatel Michal Páleník <michal....@freemap.sk>
> napsal:
>
> > ahojte
> >
> > snažím sa v rámci transakcie nahradiť tabuľku inou (drop+create). toto
> > ale zlyhá, lebo tabuľka je súčasťou view. našiel som zopár stránok kde
> > vcelku vysvetľujú prečo drop ide kvázi mimo transakcie, ale všetky sú
> > veľa rokov staré (postgres 9*). predpokladám, že dôvody stále platia.
> >
> > dáta prehadzuje z backendového serveru, kde ich zopár hodín ráta. viem
> > to zmeniť na truncate+copy ale občasne mením stĺpce a drop+create je
> > blbovzdornejšie.
> >
> > (vlastne neviem akú mám otázku, len či to je naozaj tak)
> >
> > skrátený sql, ktorý zlyhá na drop table:
> >
> > create table tmp_dd1 (id int);
> > create view tmp_dd2 as select * from tmp_dd1;
> >
> > begin;
> > drop table tmp_dd1;
> > -- cannot drop table tmp_dd1 because other objects depend on it
> > create table tmp_dd1 (id int);
> > commit;
> >
> >
> cascade nepomuze?
>

pomôže, len po skončení chcem mať view znova funkčný, teda by som ho
musel nanovo vytvoriť.

to mi príde menej komplikované ako truncate + insert (a strážiť aby som
nič nezmenil v stĺpcoch tabuľky)

michal

>
>
> Pavel
>
>
> >
> >
> >
> > --
> > michal palenik
> > www.freemap.sk
> > www.oma.sk
> >
> > --
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> > PostgreSQL-cz ve Skupinách Google.
> > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> > zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> > Chcete-li zobrazit tuto diskusi na webu, navštivte
> > https://groups.google.com/d/msgid/postgresql-cz/YO2LD2pYY7IFuOxW%40tanicka.iz.sk
> > .
> >
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

> Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB-U_4U7tqxp%2BGW6mhJEHFNdGN%3DujVgJTiuKY-0PTAX%3DA%40mail.gmail.com.

[Pavel Stehule]

út 13. 7. 2021 v 18:46 odesílatel Michal Páleník <michal....@freemap.sk> napsal:

On Tue, Jul 13, 2021 at 02:48:22PM +0200, Pavel Stehule wrote:
> út 13. 7. 2021 v 14:46 odesílatel Michal Páleník <michal....@freemap.sk>
> napsal:
>
> > ahojte
> >
> > snažím sa v rámci transakcie nahradiť tabuľku inou (drop+create). toto
> > ale zlyhá, lebo tabuľka je súčasťou view. našiel som zopár stránok kde
> > vcelku vysvetľujú prečo drop ide kvázi mimo transakcie, ale všetky sú
> > veľa rokov staré (postgres 9*). predpokladám, že dôvody stále platia.
> >
> > dáta prehadzuje z backendového serveru, kde ich zopár hodín ráta. viem
> > to zmeniť na truncate+copy ale občasne mením stĺpce a drop+create je
> > blbovzdornejšie.
> >
> > (vlastne neviem akú mám otázku, len či to je naozaj tak)
> >
> > skrátený sql, ktorý zlyhá na drop table:
> >
> > create table tmp_dd1 (id int);
> > create view tmp_dd2 as select * from tmp_dd1;
> >
> > begin;
> > drop table tmp_dd1;
> > -- cannot drop table tmp_dd1 because other objects depend on it
> > create table tmp_dd1 (id int);
> > commit;
> >
> >
> cascade nepomuze?
>

pomôže, len po skončení chcem mať view znova funkčný, teda by som ho
musel nanovo vytvoriť.

tohle v Postgresu nejde. Interne je pohled ulozeny jako AST, kde uz jsou reference nahrazene unikatnimi ciselnymi identifikatory. Pokud dropnu tabulku, musim dropnout i zavisle objekty, ponevadz jinak by ty reference byly neplatne. Vy sice pohled vidite jako SQL, ale to je dekompilace z AST do SQL. SQL se uklada napriklad v PL/pgSQL (znam zdrojovy kod procedury i zdrojove kody jednotlivych SQL prikazu, i raw vystup z parseru), a tam je system schopny si refreshnout reference, pokud budou neplatne. U pohledu to ale nikdo jeste nenapsal.

Pavel

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/YO3Dcof2nK%2B7lSTX%40tanicka.iz.sk.

[Michal Páleník]

On Tue, Jul 13, 2021 at 07:43:22PM +0200, Pavel Stehule wrote:
> út 13. 7. 2021 v 18:46 odesílatel Michal Páleník <michal....@freemap.sk>

takže v princípe by to išlo, ale ešte nikoho to netrápilo tak, aby to
doprogramoval.


druhé čo by ma potešilo je

v CREATE TABLE aby bolo aj
GENERATED ALWAYS AS ( generation_expr ) VIRTUAL
(a nie STORED)

ale už sme trošku off topic...

> > https://groups.google.com/d/msgid/postgresql-cz/YO3Dcof2nK%2B7lSTX%40tanicka.iz.sk

> > .
> >
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

> Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB8Qdj5SLkhZ_iAgVSA1eZpGVQ_zG%2BTN%2BCuLBbOOToE9A%40mail.gmail.com.

[Pavel Stehule]

> > > cascade nepomuze?
> > >
> >
> > pomôže, len po skončení chcem mať view znova funkčný, teda by som ho
> > musel nanovo vytvoriť.
> >
>
> tohle v Postgresu nejde. Interne je pohled ulozeny jako AST, kde uz jsou
> reference nahrazene unikatnimi ciselnymi identifikatory. Pokud dropnu
> tabulku, musim dropnout i zavisle objekty, ponevadz jinak by ty reference
> byly neplatne. Vy sice pohled vidite jako SQL, ale to je dekompilace z AST
> do SQL. SQL se uklada napriklad v PL/pgSQL (znam zdrojovy kod procedury i
> zdrojove kody jednotlivych SQL prikazu, i raw vystup z parseru), a tam je
> system schopny si refreshnout reference, pokud budou neplatne. U pohledu to
> ale nikdo jeste nenapsal.

takže v princípe by to išlo, ale ešte nikoho to netrápilo tak, aby to
doprogramoval.

v principu jde skoro vsechno, horsi je to naprogramovat :-).

Tohle je dost dlouho v ToDo - aktualni reseni je jednoduche, rychle, spolehlive, ale tech nevyhod je dost:

1. U view si postgres nepamatuje originalni formatovani (coz by se nekdy hodilo)

2. altrovani slozitejsich pohledu je opruz

Nicmene napsat neco lepsiho neni prace na tyden - musi se resit validita pohledu. Docela by bodla automaticka revalidace - nevim, jak je to ted, ale kompilace nevalidnich view na Oracle je taky opruz. A do toho je v potreba brat ohled na zamky, a na to, ze stejne jako ostatni hodnoty v Postgresu, i pohledy teoreticky mohou existovat ve vice verzich. ALTER, DROP, CREATE jsou v Postgresu transakcni prikazy.

Takze vubec vymyslet jak by se to melo chovat je na bednu. A mam pocit, ze se do toho ted nikdo nema (a ani se nedivim). Puvodne systemove tabulky nebyly multigeneracni - ale ted uz jsou.

 

druhé čo by ma potešilo je

v CREATE TABLE aby bolo aj
GENERATED ALWAYS AS ( generation_expr ) VIRTUAL
(a nie STORED)

Tam je taky nejaky zadrhel - mam pocit, ze uz to bylo zamergovany, a pak se to z nejakeho duvodu revertovalo. V mailinglistu se da dohledat duvod. I kdyz tady si myslim, ze je to resitelne. Tohle programoval Peter E, a mam pocit, ze toho ma presprilis - takovych ruznych nedodelavek ma dost - ale taky toho dost napsal - a nejsou lidi. A firmy, ktere plati vyvojare tohle moc nebere.

Pavel

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/YO3XJ5X/cDWC4dJx%40tanicka.iz.sk.

[Michal Bartak]

Mne to trapilo, proto nemam rad pohledy. misto nich pouzivam funkce.

Nepochopil jsem ale proc tak ti vadi ty pohledy znovu vytvorit po vytvoreni tabulky? dokonce muzes si jejich definice nacist pred dropnutim a pak vytvorit uple stejne.

Michal Bartak

> 13. 7. 2021 v 20:11, Michal Páleník <michal....@freemap.sk>:

[Petr Boháč]

Ahoj,

jeste jedna poznamka, jestli na ty tabulce mas nejakej jinej index, nez jen primarni klic, tak je pravdepodobne vyhodnejsi delat drop tabulky, import dat a pak indexace. Zejmena GIN a GIST indexy hromadne importy uplne rozsekaj a je treba udelat reindex. A stejne jako kolega nechapu, proc mas problem s vytvarenim toho view. To chleba nezere a je to prakticky instantni.

Petr

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/YO3Dcof2nK%2B7lSTX%40tanicka.iz.sk.

[Michal Páleník]

On Wed, Jul 14, 2021 at 01:19:20AM +0200, Petr Boháč wrote:
> Ahoj,
> jeste jedna poznamka, jestli na ty tabulce mas nejakej jinej index, nez jen
> primarni klic, tak je pravdepodobne vyhodnejsi delat drop tabulky, import
> dat a pak indexace. Zejmena GIN a GIST indexy hromadne importy uplne
> rozsekaj a je treba udelat reindex.

aj preto robím drop + create.

> A stejne jako kolega nechapu, proc mas
> problem s vytvarenim toho view. To chleba nezere a je to prakticky
> instantni.

lebo ten view (resp 2x view) robím inde a bojím sa, že ich zabudnem
niekedy urobiť. vlastne ten view je taký master view, čo spája asi 15
tabuliek do jednej tabuľky/view (teda by som musel 15x nezabudnúť
znovaurobiť views).
tento view má oveľa menej stĺpcov ako podkladové tabuľky plus má nejaké virtuálne.

aj som dumal urobiť to ako partitions ale kazia mi to tie neexistujúce
virtuálne stĺpce (napr pospájanie stĺpcov do ľudského popisu, samozrejme
to spájanie je v každej tabuľke iné).

michal

> > https://groups.google.com/d/msgid/postgresql-cz/YO3Dcof2nK%2B7lSTX%40tanicka.iz.sk

> > .
> >
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

> Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAJj4Mw4aqPRVh2StTK46AoKxU6Tw%2BCcsgzF-xRHtVxrbAcVW8w%40mail.gmail.com.

[Pavel Stehule]

st 14. 7. 2021 v 8:37 odesílatel Michal Páleník <michal....@freemap.sk> napsal:

On Wed, Jul 14, 2021 at 01:19:20AM +0200, Petr Boháč wrote:
> Ahoj,
> jeste jedna poznamka, jestli na ty tabulce mas nejakej jinej index, nez jen
> primarni klic, tak je pravdepodobne vyhodnejsi delat drop tabulky, import
> dat a pak indexace. Zejmena GIN a GIST indexy hromadne importy uplne
> rozsekaj a je treba udelat reindex.

aj preto robím drop + create.

> A stejne jako kolega nechapu, proc mas
> problem s vytvarenim toho view. To chleba nezere a je to prakticky
> instantni.

lebo ten view (resp 2x view) robím inde a bojím sa, že ich zabudnem
niekedy urobiť. vlastne ten view je taký master view, čo spája asi 15
tabuliek do jednej tabuľky/view (teda by som musel 15x nezabudnúť
znovaurobiť views).
tento view má oveľa menej stĺpcov ako podkladové tabuľky plus má nejaké virtuálne.

mozna by se ti hodila dedicnost

https://www.postgresql.org/docs/current/tutorial-inheritance.html

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/YO6GJPLZyjLp%2B9zu%40tanicka.iz.sk.

[Jiří Fejfar]

On Tue, 13 Jul 2021 at 20:33, Pavel Stehule <pavel....@gmail.com> wrote:

Takze vubec vymyslet jak by se to melo chovat je na bednu. A mam pocit, ze se do toho ted nikdo nema (a ani se nedivim). Puvodne systemove tabulky nebyly multigeneracni - ale ted uz jsou.

mně přijde super stávající chování: že když si vytvořím pohled, tak mám nějakou jistotu (DB hlídá), že se nezmění sloupce ze kterých pohled čerpá a tudíž pohled funguje... návazně mi připadne lepší být donucen upravit pohledy, když měním podkladovou tabulku než na to zapomenout a pak zjistit, že pohledy nefungují (což by ses stalo u plpgsql funkce, pokud bych ji neměl v regresních testech).

truncate + insert + reindex + analyze

nebo

drop + znovuvytvoření pohledů

mi přijde jednodušší, než si regresními testy hlídat funkčnost všech funkcí

[Pavel Stehule]

st 14. 7. 2021 v 10:04 odesílatel Jiří Fejfar <juraf...@gmail.com> napsal:

Ono je to robustni by design, coz je vyhoda. Tohle se neda nechtene rozbit. Na druhou stranu, obcas je opruz, ze musis mit definice pohledu externe. U vetsich projektu to mit budes, ale u mensich je to tezkopadny.

Dovedl bych si predstavit neco ve smyslu

ALTER TABLE xxx ADD COLUMN xx RECREATE DEPENDINGS;

Jsou tam stejna rizika jako u CASCADE, ale obcas se to muze hodit - kdyz mas zalohu :)

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CA%2B8wVNU6djGDTnqKgR2OObuqQt6uROcEL3aHncgL2nm4WWbvRQ%40mail.gmail.com.

[Michal Páleník]

On Wed, Jul 14, 2021 at 08:49:02AM +0200, Pavel Stehule wrote:
> > lebo ten view (resp 2x view) robím inde a bojím sa, že ich zabudnem
> > niekedy urobiť. vlastne ten view je taký master view, čo spája asi 15
> > tabuliek do jednej tabuľky/view (teda by som musel 15x nezabudnúť
> > znovaurobiť views).
> > tento view má oveľa menej stĺpcov ako podkladové tabuľky plus má nejaké
> > virtuálne.
> >
>
> mozna by se ti hodila dedicnost
>
> https://www.postgresql.org/docs/current/tutorial-inheritance.html

takže inheritance je všeobcecnejšie ako partitioning ale kopu vecí
nevie automaticky ako partition (insert do správnej tabuľky, lepšia
optimalizácia planneru)

asi nevie povedať, z ktorej tabuľky ťahám - nejaký virtuálny stĺpec aby
som vedel či mi dáta prišli z tabuľky cities alebe capitals (napr ak mám
samostatné tabuľky na pobočky aby som vedel v ktorej pobočke to našiel,
podľa názvu tabuľky bez nejakých špeci stĺpcov) (ale to nevie ani
partitioning) (?)

a asi nevie virtuálne stĺpce - napr mám tabuľky cities_uk (elevation
in meters) a cities_us (elevation in feet) tak v tabuľke cities bude
(extra) stĺpec elevation vždy v metroch.

>
>
>
> > aj som dumal urobiť to ako partitions ale kazia mi to tie neexistujúce
> > virtuálne stĺpce (napr pospájanie stĺpcov do ľudského popisu, samozrejme
> > to spájanie je v každej tabuľke iné).
> >
> > michal

[Pavel Stehule]

st 14. 7. 2021 v 13:32 odesílatel Michal Páleník <michal....@freemap.sk> napsal:

On Wed, Jul 14, 2021 at 08:49:02AM +0200, Pavel Stehule wrote:
> > lebo ten view (resp 2x view) robím inde a bojím sa, že ich zabudnem
> > niekedy urobiť. vlastne ten view je taký master view, čo spája asi 15
> > tabuliek do jednej tabuľky/view (teda by som musel 15x nezabudnúť
> > znovaurobiť views).
> > tento view má oveľa menej stĺpcov ako podkladové tabuľky plus má nejaké
> > virtuálne.
> >
>
> mozna by se ti hodila dedicnost
>
> https://www.postgresql.org/docs/current/tutorial-inheritance.html

takže inheritance je všeobcecnejšie ako partitioning ale kopu vecí
nevie automaticky ako partition (insert do správnej tabuľky, lepšia
optimalizácia planneru)

asi nevie povedať, z ktorej tabuľky ťahám - nejaký virtuálny stĺpec aby
som vedel či mi dáta prišli z tabuľky cities alebe capitals (napr ak mám
samostatné tabuľky na pobočky aby som vedel v ktorej pobočke to našiel,
podľa názvu tabuľky bez nejakých špeci stĺpcov) (ale to nevie ani
partitioning) (?)

to se asi da - muzete si vratit tableoid

postgres=# create table xx(a int);
CREATE TABLE
postgres=# insert into xx values(10);
INSERT 0 1
postgres=# select tableoid::regclass, * from xx;
┌──────────┬────┐
│ tableoid │ a  │
╞══════════╪════╡
│ xx       │ 10 │
└──────────┴────┘
(1 row)

a asi nevie virtuálne stĺpce - napr mám tabuľky cities_uk (elevation
in meters) a cities_us (elevation in feet) tak v tabuľke cities bude
(extra) stĺpec elevation vždy v metroch.

nevim, je to klasicka tabulka - a aktualne pg neumi virtualizovane generovane sloupce obecne

je na to trik

https://www.enterprisedb.com/blog/creating-virtual-columns

ale musi se pak na sloupec pouzit explicitni odkaz

>
>
>
> > aj som dumal urobiť to ako partitions ale kazia mi to tie neexistujúce
> > virtuálne stĺpce (napr pospájanie stĺpcov do ľudského popisu, samozrejme
> > to spájanie je v každej tabuľke iné).
> >
> > michal

--
michal palenik
www.freemap.sk
www.oma.sk

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/YO7LNpnOihZ0kW%2Ba%40tanicka.iz.sk.

[Jan Michálek]

Tohle jde udělat buď tak, že přes pg_depend vytáhneš oid pohledu (jde i rekurzivně přes rekurizvní cte), definici pohledu si schováš (pg_get_viewdef) například do proměnný pomocí \gset, smažeš, uděláš, co je třeba a z definice ho obnovíš. Celý to budeš mít v transakci, čiliže pokud by se něco nepovedlo, tak se to celý neprovede. Nesmíš zapomenout uložit si práva (aclexplode na relacl v pg_class) a pak je vrátit.

Druhá možnost je udělat placeholder tabulku, kde opráskneš strukturu mazané tabulky z katalogu, pak projedeš definici replacem, za tabulku, kterou mažeš dáš placeholder (replace a pg_get_viewdef), create or replace, promažeš, naplníš... a opačně.

Další možnost, jak tu někdo psal, je použití funkcí místo pohledů, ty tohle nehlídají, ale ty mají ase svoje jiný úskalí.

A nebo tabulku nemazat.

Je;

st 14. 7. 2021 v 14:51 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRCGoAdcUcK1drrzB4F1EogahsiZ3GYoqg4-nbjunbEkbA%40mail.gmail.com.

--

Jelen

Starší čeledín datovýho chlíva