On 9/24/20 10:40 PM, tutiluren@xxxxxxxxxxxx wrote:
Well not partial as in incremental. Instead dump only some portion
of the schema with or without its associated data.
It's funny that you should bring that up, considering how it was one of
my points... See the point about pg_dump's bug on Windows.
Yes, I read your bug
report(https://www.postgresql.org/message-id/MCk38UV--3-2@xxxxxxxxxxxx)
and you where just as resistant to advice there as here.
I'm saying that PostGIS has a bug due to incorrectly constructed
internal queries which makes it impossible to properly name the
schema where PostGIS is to reside, causing my database to look
very ugly when it has to say "postgis" instead of "PostGIS" for
PostGIS's schema. And that was an example of how sloppy/bad
third-party things always are, and is one reason why I don't
like it when I have to rely on "extensions".
If that is the sum of your issues with PostGIS then I really don't
have much sympathy.
Why does nobody understand that it was an *example* and not some kind of
full PostGIS review?
They are extensions so you aren't required to use them and rely on
their way of doing things. You have the choice of writing your own
code/extension or do without completely.
It sure is great to have such choices... I can't take it seriously when
people say things like this. It's similar to "it's open source so you
can easily vet it yourself". It's not taking reality into consideration
at all.
As for doing without it, that would make it impossible to deal with GPS
coordinates/maps. So it's not really a choice at all.
Read this issue from PostGIS:
https://trac.osgeo.org/postgis/ticket/3496
" Then we can use the variable @extschema@ in lieu of the actual schema
name. This will still allow users to do:
CREATE EXTENSION postgis SCHEMA whereever_I_damn_want_you_to_be;
"
It is more then that. It would have to take into account the
behavior changes that happen in Postgres between major versions. It
also would have to account for OS specific parameters and the
changes that happen there between OS versions. It also would need to
'know' how the database was going to be used; readonly, heavy
writes, etc. Also how the database should play with other programs
on the same machine. Add to the mix containers, cloud instances and
so on and you are outrunning the ability of 'ifs' to handle it.
If it changes that much, it's far, far worse than I even thought, and it
sounds like it will be pointless to even *try* to learn it as it keeps
changing between versions/OSes/other stuff.
Life is not static. If you want to stay current you have to keep learning.
I can't help but feel as if people just don't want to answer this and
other concerns I have. As if there's some silent agreement along the
lines of "securing PG DBAs' jobs".
The reason people have not answered is you have not provided the
information necessary to formulate an answer. For instance, OS &
version, Postgres version, size of data, database use case, number of
users.
The thing is 'general mode' is going to mean something different to
someone running a database in the MB-low GB range vs. high GB vs. TB
vs. PB.
I don't mean this to sound rude, but it's like talking to a wall... What
I mean is that there are obviously technical means for software to know
whether they are exhausting the system they are running on or not, and
expecting people to understand all these intricate internal parameters
is just... bizarre. There ought to be some kind of "abstract" setting
for those of us who aren't able to (or even *wish* to) comprehend all
the PG internals, and just want an efficient database using (roughly) as
much of our machine as we want.
This is not the first time I feel like I'm repeating myself over and
over in different ways but never getting through. It could be that you
are so familiar with PG's internals that it all is obvious to you, but
it could just as well be that you don't want to hear about this.
No I am not all that familiar with the Postgres internals. I'm an end
user for what qualifies as small databases. The configuration as is
works for me, in that any impediments it might impose are hidden by
other parts of the stack. I just know, from years on this list, that
there are folks who would help you with configuration given some
starting point information.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
