Re: Oracle vs. PostgreSQL - a comment

2021-04-29 Thread ERR ORR
I may be off-topic as I've only worked occasionally with ORA but still know
it good enough.
What I miss most of the Oracle DB in PostgreSQL is the elaborate system of
object security and granting permissions which exists in Oracle DB.
What I like most about the Postgres DB is that lots of plugins/extensions
exist which implement features which do not exist in the basic feature set,
and it is comparatively easy to program extensions which you need.
There are lots more things which make me prefer PostgreSQL.
I think that is PostgreSQL included a security system comparable to Oracle,
that would be a firm Plus in the market.

On Thu, Apr 29, 2021, 19:13 Paul Förster  wrote:

> Hi Ludovico,
>
> > Sorry for this reply, but I feel it is necessary to make it clear what
> is reality and what is FUD against Oracle from Paul's e-mails in this
> thread...
>
> nothing of it was a FUD. It was a comparison done on a single machine.
> Then, I drew my conclusions from that and added my personal view. You don't
> necessarily havet to agree to my opinion nor did I ask you to agree. But
> it's definitely not FUD!
>
> > (Note: I work for Oracle now, but I've had 20 years experience as
> multi-platform database consultant)
>
> I work *with* Oracle databases too and have been for 20+ years. But I do
> not work *for* Oracle and I don't feel inclined to spread their advertising.
>
> > That is... not a problem. Is it, for real?
>
> technically no. Still, a) it makes no sense at all to advertise a 64 bit
> product that still needs 32 bit support (one could even call that an
> advertising lie!) and b) it may (or may not?) cost performance.
>
> > Although I completely agree that the Oracle installation process is much
> longer and more complex than PostgreSQL, I disagree with the rest.
>
> to create a CDB, you still have to provide paths which are then hard-coded
> into the control-file! Oracle software takes tons of space and the
> installation takes longer.
>
> > The CREATE PLUGGABLE DATABASE is also a single line SQL command... The
> scripts to create a PDB or a PostgreSQL database depend a lot on what do
> you want to achieve (empty database? specific users or permissions? sanity
> checks? pre-emptive backup? add to cmdb?)
>
> yes, create pluggable database. Takes 30+ secs to run, while on
> PostgreSQL, it takes a few milliseconds. But we require a certain structure
> in the filesystem which makes the thing much more complex.
>
> > For a new PostgreSQL architecture in the past I have written 230 lines
> of code to automate the database creation in an existing PostgreSQL
> cluster. That included setting up application users, hardening the default
> permissions on the public schema, registering in the CMDB, etc. It is not
> much code in my opinion and it is done once for all.
>
> again, a simple initdb, or create database would do. For all to be done in
> PostgreSQL, my script is some 30 lines and includes default user creation,
> revoking some stuff, etc., nothing compared to what I need for Oracle.
>
> > This is bashing FUD against Oracle or lack of basic Oracle knowledge.
> Oracle online move, reorganization and patching capabilities are far ahead
> from PostgreSQL.
>
> nonsense!
>
> > Online Datafile Movement has existed since 12cR1. 8 years!
> https://oracle-base.com/articles/12c/online-move-datafile-12cr1
>
> yes, I know. But did you try to move SYSTEM, UNDO or TEMP tablespace or
> online redo log files? Did you try to move the *whole* database? You can
> move all data/index tablespace files with that (one by one which is
> tiresome with many files), but you can't move the essential tablespace
> files! Well, you can move the online reado log files by creating new ones
> and dropping the old ones but that's about it. You still can't move the
> essential tablespace files. I admit that I didn't try that with 19.x but it
> wasn't possible up to now.
>
> > Prior to that, for many years, it was possible to offline, move, rename
> and online datafiles, either grouped or singularly, without stopping the
> instance. Online logs can be rotated to a new location online. The only
> exception are the controlfiles that require an ALTER SYSTEM, shutdown,
> move, startup.
>
> I know all that but it still requires far to much work! And it still
> doesn't move the while database!
>
> > PostgreSQL must be stopped in order to move the database to a new path,
> and if it is to a new filesystem, you need the time for a full copy of the
> data, unless you do it via backup and recovery to reduce the downtime.
>
> that's not true. pg_basebackup it while running to a new destination. Set
> up primary_conn_info and replication and start up the copy. Once it's in
> sync and you have a physical copy, change the port in postgresql.conf of
> the copy, stop both and then only launch the copy. Promote it then. The
> switch takes 2-3 secs of downtime.
>
> If downtime doesn't matter but space does, stop the database cluster, move
> the whole PGDATA to a new 

Request clarification w/ PG_DUMPALL -d.

2020-08-30 Thread ERR ORR
I'm trying to migrate a 9.5 DB to a current version using PG_DUMPALL.
It reclaims that what I pass in the -d parameter is missing a "=" and the
man directs me to look at chapter 31.1.1 Connection Strings of the dox PDF.
The Problem is that there are different connection strings listed there and
I don't know which one I should use.
Would be happy if somebody could clarify exactly what value/s I need to use
for the -d parameter of PG_DUMPALL.


Re: Code of Conduct plan

2018-09-19 Thread ERR ORR
I see a CoC as an infiltration of the PostgreSQL community which has worked
OK since at least 10 years.
The project owners have let their care slacken.
I request that the project owners EXPEL/EXCOMMUNICATE ALL those who are
advancing what can only be seen as an instrument for harassing members of a
to-date peaceful and cordial community.

THROW THESE LEFTIST BULLIES OUT‼️

Dimitri Maziuk  schrieb am Mo., 17. Sep. 2018, 19:21:

> On 09/17/2018 10:39 AM, Chris Travers wrote:
> > On Mon, Sep 17, 2018 at 5:28 PM Joshua D. Drake 
> > wrote:
> ...
> >> My feedback is that those two sentences provide an overarching authority
> >> that .Org does not have the right to enforce
> ...
> > Fascinating that this would, on its face, not apply to a harassment
> > campaign carried out over twitter, but it would apply to a few comments
> > made over drinks at a bar.
>
> There is a flip side: if you have written standards, you can be held
> liable for not enforcing them. Potentially including enforcement of
> twitbook AUP on the list subscribers who also have a slackogger account.
>
> --
> Dimitri Maziuk
> Programmer/sysadmin
> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
>
>


Re: Code of Conduct committee: call for volunteers

2018-06-27 Thread ERR ORR
I am apparently late in this discussion.
I COMPLETELY DISAGREE with the idea of having a CoC in Postgres.
I've participated for many years in the lists and don't remember one
instance of inappropriate behavior.
A CoC will only contribute to decrease the quality of the Postgres code.
How? It will entrench women and fags in the Postgres community.
Having worked many years with women, I can say from experience that most of
them are incompetent AF.
Fags are that plus disgusting.
I hope that you'll consider the CoC well.
It is an enmitous takeover.

Tom Lane  schrieb am Do., 7. Juni 2018, 22:58:

> The proposed Postgres Code of Conduct [1] calls for an investigation
> and enforcement committee, which is to be appointed by and ultimately
> answerable to the core team, though no core members may sit on it.
>
> The core team is pleased to announce that Stacey Haysler has agreed
> to serve as the first Chair of the CoC committee.  Many of you know
> Stacey from various conferences etc, and I don't feel that I need to
> repeat her excellent qualifications for this task.
>
> While we have a few names in mind for additional committee members,
> we need more in order that the committee can represent a diverse
> range of viewpoints and cultures.  Therefore we are calling for
> volunteers, as indeed is required by the proposed CoC.  This call
> will remain open until June 15; the committee membership will be
> decided and announced before the end of June.
>
> We encourage community members who, perhaps, have not previously
> taken large roles in the community to step forward for this.
> What is needed is not technical skills but empathy and the ability
> to understand varying viewpoints.
>
> If you are interested in serving, please write to c...@postgresql.org
> (do not follow up to this message).  Please include answers to these
> questions:
>
> 1. What interests you about being on the CoC Committee?
>
> 2. Have you been on another CoC Committee, or had a similar role at
> another organization?  (Prior experience is not required, it's just
> helpful to know everyone's background.)
>
> 3. What else would you like to tell us that is helpful for us to know
> about your potential involvement with the CoC Committee?
>
>
> regards, tom lane
>
> [1] https://wiki.postgresql.org/wiki/Code_of_Conduct
>
>