Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> > Alvaro Herrera <alvherre@commandprompt.com> wrote:
> >> If you're feeling corageous, you can remove the pg_depend
> >> entries for that sequence. Make sure to try it in a
> >> transaction and drop
>
> > I'd like to understand better the risks of being courageous?
> > I think my life would be easier if I'd know when it is safe to
> > put hands in the system tables.
>
> Well, it's safe if (a) you know what you're doing, (b) you don't
> make any mistakes, and (c) you don't forget any changes needed to
> keep all the catalogs consistent.
>
> You can protect yourself against (b) by using a transaction, but
> the other two tend to require hacker-grade knowledge of how the
> backend works, so we try to discourage people from doing it.
Why hacker-grade knowledge of the backend?
With "hacker-grade" you mean: undocumented or RTSL?
Isn't the knowledge about how catalog stuff maps on SQL to "guess"
how to achieve certain results?
> pg_depend in particular tends to have rather obscure contents,
> and what's worse is that messing it up usually doesn't have any
> immediately-obvious consequences.
OK... what about concurrent works?
eg. supposing I write the correct SQL should I take care to be the
only one accessing the DB in that moment?
What could be the use case of directly accessing the catalog?
I'd like to have an idea if it is something to invest my time in.
My main interest would be refactoring.
thanks
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No comments:
Post a Comment