Proposed French Translation of Code of Conduct Policy

[Stacey Haysler]

The PostgreSQL Community Code of Conduct Committee has received a draft of
the French translation of the Code of Conduct Policy updated August
18, 2020 for
review.

The English version of the Policy is at:
*https://www.postgresql.org/about/policies/coc/
*

The translation was created by: Alice Armand

The translation was reviewed by: Guillaume LeLarge

The proposed translation is attached as both a plain text and a PDF file to
this message.

If you have any comments or suggestions for the proposed translation,
please bring them to our attention no later than 5:00 PM Pacific Time on
Friday, September 23, 2021.

Thank you.

Regards,
Stacey S. Haysler
Chair, PostgreSQL Community Code of Conduct Committee
Code de Conduite
Dernière mise à jour : 18 août 2020. Consulter l’historique des modifications.

Introduction
Le Projet PostgreSQL est fier de la qualité de son code et de son travail, et 
des réalisations techniques et professionnelles de sa communauté. Nous 
attendons de tous les participants qu'ils se conduisent de manière 
professionnelle, en agissant avec courtoisie et dans l'intérêt commun, dans le 
respect de tous les utilisateurs et développeurs.
À ces fins, nous avons établi ce Code de conduite pour l'interaction et la 
participation de la communauté aux travaux du projet et à la communauté dans 
son ensemble. Ce Code est censé couvrir toute interaction entre les membres de 
la communauté, qu'elle ait lieu ou non au sein de l'infrastructure 
postgresql.org, pour autant qu'aucun autre Code de Conduite ne prévale (tel que 
le Code de Conduite d'une conférence).

Inclusivité et conduite appropriée
Le Projet PostgreSQL est ouvert à la participation de toute personne intéressée 
par le travail avec PostgreSQL, quel que soit son niveau d'expérience avec le 
logiciel, ou avec la technologie en général. Nous encourageons le développement 
et les contributions de tous les utilisateurs, quelle que soit leur formation.
Nous encourageons les discussions réfléchies et constructives sur le logiciel 
et cette communauté, leur état actuel et les possibles directions de 
développement. Nos discussions doivent se concentrer sur le code et la 
technologie associée, les projets communautaires et l'infrastructure.
Les attaques personnelles et les commentaires négatifs sur des caractéristiques 
personnelles sont inacceptables et ne seront pas autorisés. Les exemples de 
caractéristiques personnelles comprennent, de façon non exhaustive, l'âge, la 
race, les origines nationales ou les ascendances, la religion, le genre ou 
l'orientation sexuelle.
D'autres exemples de comportements représentant également des violations de ce 
Code de Conduite sont : les menaces de violence à l'encontre d'un individu ou 
d'un groupe, les menaces de sabotage professionnel, communautaire et/ou de 
projets, les sollicitations sexuelles importunes de quelque forme que ce soit, 
les comportements susceptibles de discréditer le projet PostgreSQL, et le refus 
de stopper un comportement inapproprié malgré une demande en ce sens.

Représailles
Il est également expressément interdit à quiconque d'exercer des représailles à 
l'encontre d'une personne qui dépose une plainte en vertu du présent Code de 
Conduite, ou qui contribue à l'instruction d'une telle plainte. Les 
représailles peuvent, entre autres, se manifester par les actions suivantes :
- de nouvelles attaques personnelles (publiques ou privées) ;
- des actions qui nuisent au statut professionnel d'une personne et/ou à son 
statut auprès de son employeur, de ses collègues, de ses clients ou de la 
communauté ;
- des actions qui menacent la vie privée de l'individu, sa personne physique, 
son bien-être, son domicile et/ou sa famille.
Les actes de représailles seront traités de la même manière que toute autre 
violation du présent Code de Conduite.


Comité du Code de Conduite
La Core Team nommera un Comité du Code de Conduite chargé de recevoir et 
d'examiner toutes les plaintes, ainsi qu'un président pour ce Comité. Tout 
membre de la communauté peut se porter volontaire pour faire partie du Comité, 
à l'exception des membres de la Core Team. Étant donné que la Core Team 
supervise le Comité, les membres de la Core Team ne siégeront pas au Comité 
afin d'éviter tout conflit d'intérêt. La liste des membres du Comité sera 
accessible au public à tout moment et peut être consultée ici.
La composition du Comité sera renouvelée annuellement. La Core Team ou le 
président du Comité annonceront les dates d'ouverture et de clôture du 
processus annuel de sélection des membres par le biais des canaux de 
communication habituels de la communauté.
Tout membre de la communauté souhaitant s'engager auprès du Comité remplira un 
questionnaire initial qui sera examiné par la Core Team et le Comité en 
exercice. Les membres du Comité en exercice examineront les candidats et 
mèneront des entretiens, si nécessaire. Le Comité en exercice émettra des 

Re: The tragedy of SQL

[Arnold Morein]

My $5.00 on this discussion (quite fascinating and nostalgic actually). This is 
a little long granted, but it was fun.

As someone who cut their IT in general and programmer teeth in particular on 
the HP 3000 platform, in the time (and a land) BEFORE SQL, where we had only a 
single database engine to choose from (IMAGE, a network database), where you 
accessed data with its hashed key via a strict read/insert/lock before 
(update/delete) API or the KSAM file engine for non-database work that didn’t 
have high transaction volume (again, also only via a strict API), SQL at the 
time was nothing short of a miraculous boon!

None of the above were Relational. Nor was there anything like SQL in the 
business market. At the time, it was mostly found in academia and some 
fringe/bleeding edge companies.

Though I understand the concept of the request that started the thread, what 
irks me is when people make statements like the “tragedy of SQL” or anything 
else that equates SQL with the concept of a RDBMS. The two are not the same 
thing.

Let us not forget that SQL is an acronym for Structured Query Language and it 
is indeed just that: a language and a tool to be used in retrieving and 
manipulating data organized in the form of a tabular data stream; how it is 
managed by the underlying engine is irrelevant. By the time I was able to study 
it in college (after several years of only being to access data via a program I 
had to write utilizing engine APIs) I found it a great tool for a programmer 
and yes, even the odd accountant that had some technical aptitude. At the time, 
a basic SQL interpreter exceeded some of the best "report writer” tools of its 
day and unlike those tools, you could use SQL to actually change data in the 
underlying data store. (It’s Dark Majik, Moriarty!) In fact in many ways, it 
wasn’t marketed as a API abstraction layer (as it has turned into of late) but 
as a separate add-on tool for a given flavor of file/database engine.

Back on the HP 3000 (a 16-bit machine at that point), the only languages for 
use (that I had access to) were COBOL, Fortran, and (new at the time) Pascal. 
Having to write a quick and dirty application just to list data on the screen 
was required and overly tedious. When SQL became available as a layer between 
the user and the data store, it actually reduced the programmer workload as 
simple inquiries could be done by technical if not programming staff. (Also, 
when migrating from one propriety data source to another, SQL could be exported 
from one system and executed in another for import.)

On the other hand, from a programmer’s stand point back then, the introduction 
of the RELATIONAL database, and the cool stuff the engine would do for me with 
a one time declaration and no coding was amazing and again, a time saver. That 
there was a SQL interpreter option for the engine was icing on the cake!

HP would later release a SQL interpreter for its then TurboIMAGE and later 
ALLBASE products. The current CONNX product (now owned by SoftwareAG) provides 
SQL based access to Adabas data. IBM provides a product to provide access to 
VSAM data via SQL. Again: an add-on module to a product that wasn’t originally 
built to a be a RDBMS. 

I think the IT industry did a bit of a disservice to itself, SQL, and the RDBMS 
concept by coupling them so tightly. (Or maybe they just grew together 
organically?) The concept of a QL, whether verbose or terse, that allows a 
human with only a little training to write statements that gives them access to 
the data they need was a great idea. It still is. But, the plethora of other 
languages (for data access or other arcane activities) that have appeared in 
the field over the last 10-15 years is well, boggling; and personally at times 
seem like a rework only because the author didn’t like the language’s syntax or 
simply wasn’t a touch typist. (Man am I glad I took typing in high school!)

As stated, SQL is a language/tool that is simply one way to interact with a 
file/database engine. Though these days, I suspect many vendors prefer to use 
SQL as the only language they offer because SQL has such a broad use and most 
people have had to learn it to some degree or other in their collegiate and 
professional careers. What amazes me is that so many companies and products 
have gone to such lengths to allow the “simple” language of SQL to become the 
de facto language to interact with their file/database engines; sometimes not 
even publishing a non-SQL API at all. (All you get is a C/JDBC driver. Enjoy!)

So back to the thread, given the extensibility of PostgreSQL, I think the 
concept of a different QL to access the data stored there (or anywhere else for 
that matter) may be of great use to a specific audience, depending on the 
environment (read tool) where it is used.  (The biology reference was 
brilliant: one of my COBOL teachers digressed once that one of the features of 
the language at its outset was its 

pg_upgrade problem as locale difference in data centers

[Yi Sun]

Hello,

We want to upgrade some PG9.6 DB to PG13, the databases locale are
different in data centers, some are C, some are ru_RU.UTF-8 and so on... as
below

postgres=# select datname,datcollate,datctype from pg_database;
datname| datcollate  |  datctype
---+-+-
 postgres  | C   | C
 template1 | C   | C
 template0 | C   | C
 aaa_service  | C   | C

postgres=# select datname,datcollate,datctype from pg_database;
datname | datcollate  |  datctype
+-+-
 postgres   | ru_RU.UTF-8 | ru_RU.UTF-8
 template1  | ru_RU.UTF-8 | ru_RU.UTF-8
 template0  | ru_RU.UTF-8 | ru_RU.UTF-8
 bbb_service   | ru_RU.UTF-8 | ru_RU.UTF-8

We use 1 ansible script to proceed the upgrade in data centers, as
pg_upgrade will only work once postgres, template1, template0 3 databases
locale are same between PG9.6 and PG13, so we test before pg_upgrade,
update the 3 databases locale to 'en_US.UTF-8' both in PG9.6 and PG13 as
below script

update pg_database set datcollate='en_US.UTF-8', datctype='en_US.UTF-8'
where datname in ('postgres','template1','template0') and
(datcollate<>'en_US.UTF-8' or datctype<>'en_US.UTF-8')

Then test pg_upgrade completed with no error, but as pg documentation says
like"collation can't be changed after database creation. Only drop and
recreate", the question is if we can update and upgrade this way, will it
have problems?

Thanks and best regards
Sun Yi

Re: The tragedy of SQL

[Ron]

On 9/16/21 6:29 PM, Guyren Howe wrote:
[snip]
Missing my original point here. The set theory is the _point_. SQL is a 
gargantuan distraction from using it efficiently.


Imagine if COBOL was the only widely-available programming language with 
functions. You might use it, because functions are really great 
abstraction for programming. That wouldn’t mean that COBOL wasn’t an 
utterly awful language.


COBOL is a *great* language in its domain.

--
Angular momentum makes the world go 'round.

Re: The tragedy of SQL

[Ron]

On 9/16/21 3:21 PM, Gavin Flower wrote:

On 17/09/21 04:26, Michael Nolan wrote:
In the same 1971 seminar where we studied Algol-68, we had to read and 
write a short paper on the 1970 Codd paper on relational  theory, which 
had only been out for about a year.  The professor running the seminar 
noted that Codd proved that the relational model worked, but didn't 
guarantee that it worked efficiently enough to be implementable without 
immense computer resources, which of course became available.

--
Mike Nolan



Developing an effective optimizer might have helped ...


Just a Simple Matter of Engineering... /s

--
Angular momentum makes the world go 'round.

Re: The tragedy of SQL

[Gavin Flower]

On 17/09/21 11:29, Guyren Howe wrote:
[...]
The set theory is the _point_. SQL is a gargantuan distraction from 
using it efficiently.


Imagine if COBOL was the only widely-available programming language 
with functions. You might use it, because functions are really great 
abstraction for programming. That wouldn’t mean that COBOL wasn’t an 
utterly awful language.


SQL is like that, only for relations, sets and logic.



COBOL is horrible, but SQL is quite a neat language, though it has its 
issues.


Am happy to write SQL, but not that keen on getting back into COBOL!

SQL is far superior to COBOL, in their respective use cases.


Cheers,
Gavin

Re: Alter and move corresponding: was The tragedy of SQL

[Gavin Flower]

On 17/09/21 11:22, Rob Sargent wrote:

As far as alter, in 1981, before I became a programmer, I asked my

Cobol Programmer friend if there was anything you could put in a
program that would get you fired. He said yes, the alter statement :-).
In my 3 semesters of Cobol, I never once used the Alter statement.


[...]

I was very proud of using an ALTER GOTO in my first program in my 8 
week COBOL training course.  Now I cringe every time I think about it!


Before the course, I was fluent in FORTRAN IV and had programmed in 
ALGOL-68.  So I was an experienced programmer.



In what I see now as truly prescient of the early 80's U of BC CS 
department, algol-68, snobol, cobol, B, APL and half a dozen others 
I've complete forgoten each got a week with the same Towers of Hanoi 
task. I can only assume the powers saw the impending dump-heap 
relegation of the lot of them. The counter argument was that the major 
project was done PL/1.




I've seen some documentation for all those languages except B, but I 
never programmed in any of: SNOBOL, B, nor APL.  I was sent on a 3 day 
PL/1 course, but never used it 'in anger'.


I once tried to discuss general programming ideas with a colleague, and 
started talking about a section of code.  They then proceeded to tell me 
the definition of SECTION in COBOL in detail, I didn't bother to tell 
them that I knew 3 things about SECTIONs in COBOL that they hadn't 
mentioned.  I gave up the discussion, saw no point in continuing, and I 
didn't want to appear patronising.


Until one has programmed in several languages, preferably of different 
types, it is difficult to separate out programming concepts from the 
philosophy and implementation of individual languages.


I think any Master Programmer should have fluency in at least 3 
languages and familiarity with at least 3 more.  So I think at least 3 
languages should be taught to CS students.  And of course the importance 
of how to RTFM effectively!


Once I helped a colleague debug a Smalltalk example based on a magazine 
article I'd read 2 years earlier.  I'm certain they implicitly assumed 
that I was for more experienced in Smalltalk than I was!  Perhaps I 
should ask her, but she's probably forgotten -- that was about 30 years 
ago.  Now I've been married to her for 25 years,


Another time I helped someone develop a screen saver in Visual Basic.  
Though it was many years later before I realized the name of the 
language.  I'd never seen VB before.  I even explained the OnEvent 
concept even though it was totally new to me, but I still successfully 
helped them to implement at least one such construct in the screen 
saver.  Having experience with a wide variety of different programming 
languages was a huge advantage.



Cheers,
Gavin

Re: autocommit for multi call store procedure

[David G. Johnston]

On Thursday, September 16, 2021, Trang Le  wrote
>
>
> Could you double check it?
>

We’re testing your failing code, not that PostgreSQL is working as
intended.  Suggest you get rid of all the stuff that doesn’t produce errors
and focus on trying to supply a minimal script that produces the unexpected
error.  Then send that as a single email, probably with an attachment and
some explanations.

David J.

Re: The tragedy of SQL

[Mladen Gogala]

On 9/16/21 19:29, Guyren Howe wrote:
Missing my original point here. The set theory is the _point_. SQL is 
a gargantuan distraction from using it efficiently.


Imagine if COBOL was the only widely-available programming language 
with functions. You might use it, because functions are really great 
abstraction for programming. That wouldn’t mean that COBOL wasn’t an 
utterly awful language.


SQL is like that, only for relations, sets and logic.



I am probably a bit biased because I am using SQL for a few weeks now. I 
was the first person certified for teaching Oracle 6 internals in the 
EMEA region and I was a certified Oracle 5.1.22 DBA on VAX/VMS. So, by 
using SQL for several weeks now, I grew attached to it and I like it. My 
second problem is my mathematical background. I have a Bsc in 
mathematics and was quite well acquainted not only with the basic set 
theory but also with things like Zermelo's  axiom of choice, Zorn's 
lemma and well ordering theorem. I am still quite familiar with the 
relational algebra, unions, intersections, Cartesian products, 
equivalence relations and alike. I think that SQL represents relational 
algebra quite well. It must be doing something right, because it lasts 
for so long. After all, it was created by a mathematician. There is a 
famous quote from the move "Chinatown" saying that politicians, ugly 
buildings, and whores all get respectable if they last long enough. The 
same applies to computer languages. I love the smell of SQL in the morning.



--
I'll speak the key, the whole key and nothing but the key, so help me Codd.
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com

Re: The tragedy of SQL

[Rob Sargent]

Missing my original point here. The set theory is the _point_. SQL is 
a gargantuan distraction from using it efficiently.


Imagine if COBOL was the only widely-available programming language 
with functions. You might use it, because functions are really great 
abstraction for programming. That wouldn’t mean that COBOL wasn’t an 
utterly awful language.


SQL is like that, only for relations, sets and logic.

Is "like that" how, exactly?

Re: The tragedy of SQL

[Guyren Howe]

On Sep 16, 2021, at 7:31 , Merlin Moncure  wrote:
> 
> On Wed, Sep 15, 2021 at 7:31 PM FWS Neil  wrote:
>> On Sep 15, 2021, at 2:44 PM, Merlin Moncure  wrote:
>>> I think you ought to recognize that many people on this list make
>>> money directly from managing that complexity :-).
>> 
>> I did not intend to disparage anyone.  People, including myself, make money 
>> when they provide value and there is certainly value here.
>> 
>> But, I am not sure I understand your inference.  Are you saying (and I am 
>> not implying you are) that PostgreSQL does not progress in line with the 
>> original SQL goals of simplifying data access because people are making 
>> money off of the current complexity?
> 
> Not at all.  I'm saying that this mailing list is stuffed with people
> that work on and with the database, and SQL is in many cases
> (including mine) a passion.   Postgres is a technical marvel so that
> we make money by utilizing it effectively, and rendering, er,
> constructive feedback to its stewards so that it may improve and we
> may all become more efficient.
> 
> Points made upthread suggesting SQL is bad due to being based on sets
> were ironic IMO.  SQL is successful and enduring precisely because you
> can direct operations by describing data relationships rather than
> implement specific operations by hand.  Fluency in that technique
> leads to solution achievement that other technologies cannot approach.
> It rewards artistry and creativity, which I guess rubs some people the
> wrong way since it does not align to factory development strategies.
> 
> No offense taken; I enjoy the debate; this thread is an indulgence,
> being a bit of time off from capricious C suite executives, agile
> methodology zealots, etc. So fire away.

Missing my original point here. The set theory is the _point_. SQL is a 
gargantuan distraction from using it efficiently. 

Imagine if COBOL was the only widely-available programming language with 
functions. You might use it, because functions are really great abstraction for 
programming. That wouldn’t mean that COBOL wasn’t an utterly awful language.

SQL is like that, only for relations, sets and logic.

Re: Alter and move corresponding: was The tragedy of SQL

[Rob Sargent]

As far as alter, in 1981, before I became a programmer, I asked my

Cobol Programmer friend if there was anything you could put in a
program that would get you fired. He said yes, the alter statement :-).
In my 3 semesters of Cobol, I never once used the Alter statement.


[...]

I was very proud of using an ALTER GOTO in my first program in my 8 
week COBOL training course.  Now I cringe every time I think about it!


Before the course, I was fluent in FORTRAN IV and had programmed in 
ALGOL-68.  So I was an experienced programmer.



In what I see now as truly prescient of the early 80's U of BC CS 
department, algol-68, snobol, cobol, B, APL and half a dozen others I've 
complete forgoten each got a week with the same Towers of Hanoi task. I 
can only assume the powers saw the impending dump-heap relegation of the 
lot of them. The counter argument was that the major project was done PL/1.

Re: Alter and move corresponding: was The tragedy of SQL

[Gavin Flower]

On 16/09/21 04:52, Steve Litt wrote:

Gavin Flower said on Wed, 15 Sep 2021 13:49:39 +1200


Hi Michael,

[snip]


COBOL has strange verbs like 'move corresponding' that could
accomplish complicated tasks in a few lines but you have to be
careful that you knew what you were asking for!

In our site that was banned as being too dangerous.

And how about the 'lovely' ALTER GOTO construct???

Children don't try to use these constructs at home, as even
experienced adults get burnt using them!

I never Cobolled professionally, but took 3 semesters of Cobol and
Santa Monica Community College in Santa Monica, California USA. They
taught us move corresponding, I used it, it was handy. I'd use it again
if I were a Cobol professional.

As far as alter, in 1981, before I became a programmer, I asked my
Cobol Programmer friend if there was anything you could put in a
program that would get you fired. He said yes, the alter statement :-).
In my 3 semesters of Cobol, I never once used the Alter statement.


[...]

I was very proud of using an ALTER GOTO in my first program in my 8 week 
COBOL training course.  Now I cringe every time I think about it!


Before the course, I was fluent in FORTRAN IV and had programmed in 
ALGOL-68.  So I was an experienced programmer.



Cheers,
Gavin



Cheers,
Gavin

Re: The tragedy of SQL

[Gavin Flower]

On 17/09/21 04:26, Michael Nolan wrote:
In the same 1971 seminar where we studied Algol-68, we had to read and 
write a short paper on the 1970 Codd paper on relational  theory, 
which had only been out for about a year.  The professor running the 
seminar noted that Codd proved that the relational model worked, but 
didn't guarantee that it worked efficiently enough to be implementable 
without immense computer resources, which of course became available.

--
Mike Nolan



Developing an effective optimizer might have helped ...


Cheers,
Gavin

Re: Alter and move corresponding: was The tragedy of SQL

[Michael Nolan]

One of the grad students in the computer center had a sign on his wall:
God is real, but Man is only an integer.
--
Mike Nolan

Re: The tragedy of SQL

[Michael Nolan]

In the same 1971 seminar where we studied Algol-68, we had to read and
write a short paper on the 1970 Codd paper on relational  theory, which had
only been out for about a year.  The professor running the seminar noted
that Codd proved that the relational model worked, but didn't guarantee
that it worked efficiently enough to be implementable without immense
computer resources, which of course became available.
--
Mike Nolan

Re: The tragedy of SQL

[Merlin Moncure]

On Wed, Sep 15, 2021 at 7:31 PM FWS Neil  wrote:
> On Sep 15, 2021, at 2:44 PM, Merlin Moncure  wrote:
> > I think you ought to recognize that many people on this list make
> > money directly from managing that complexity :-).
>
> I did not intend to disparage anyone.  People, including myself, make money 
> when they provide value and there is certainly value here.
>
> But, I am not sure I understand your inference.  Are you saying (and I am not 
> implying you are) that PostgreSQL does not progress in line with the original 
> SQL goals of simplifying data access because people are making money off of 
> the current complexity?

Not at all.  I'm saying that this mailing list is stuffed with people
that work on and with the database, and SQL is in many cases
(including mine) a passion.   Postgres is a technical marvel so that
we make money by utilizing it effectively, and rendering, er,
constructive feedback to its stewards so that it may improve and we
may all become more efficient.

Points made upthread suggesting SQL is bad due to being based on sets
were ironic IMO.  SQL is successful and enduring precisely because you
can direct operations by describing data relationships rather than
implement specific operations by hand.  Fluency in that technique
leads to solution achievement that other technologies cannot approach.
It rewards artistry and creativity, which I guess rubs some people the
wrong way since it does not align to factory development strategies.

No offense taken; I enjoy the debate; this thread is an indulgence,
being a bit of time off from capricious C suite executives, agile
methodology zealots, etc. So fire away.

merlin

Re: autocommit for multi call store procedure

[Adrian Klaver]

On 9/16/21 12:36 AM, Trang Le wrote:

Hi guys,

I am using pgadmin4 to interact with Postgres database. For now I would 
like to run 2 store procedure (those have commit statement in begin end 
block). I enable autocommit and run call 2 store procedures at the same 
time. However, there is an error with invalid transaction termination.


Could you help me on this issue?


Maybe but will need to see:

1) The content of the procedures.

2) The manner in which they are called.

3) The actual complete error message.



Thanks,
Trang



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: The tragedy of SQL

[Edson Carlos Ericksson Richter]

Em 15/09/2021 21:55, Adrian Klaver escreveu:

On 9/15/21 5:30 PM, FWS Neil wrote:



On Sep 15, 2021, at 2:44 PM, Merlin Moncure > wrote:





I think you ought to recognize that many people on this list make
money directly from managing that complexity :-).



I did not intend to disparage anyone.  People, including myself, make 
money when they provide value and there is certainly value here.


But, I am not sure I understand your inference.  Are you saying (and 
I am not implying you are) that PostgreSQL does not progress in line 
with the original SQL goals of simplifying data access because people 
are making money off of the current complexity?




I'm going to say Merlin was being one part sarcastic, one part saying 
people may not want to bite the hand that feeds them.


As to SQL, if Postgres wants to maintain it's goal of hewing to the 
SQL standard then what progress it came make is determined by the SQL 
standards committee.



I love the fact that PostgreSQL keep in sync with SQL standard. I love 
SQL as it is (and I came from a world with Cobol, Clipper and Dbase, and 
other 4GL etc tools).


Also, I teach SQL to my junior employees, and they love it once they 
fully compreehends - even stop defending the NoSQL hype.


At other side, I would see no objection if someone else would implement 
another language on top of PostgreSQL engine.



Just my 2c.

Regards,

Edson

Re: autocommit for multi call store procedure

[Ninad Shah]

Have you used an EXCEPTION block in the procedure?


Regards,
Ninad Shah

On Thu, 16 Sept 2021 at 13:06, Trang Le  wrote:

> Hi guys,
>
> I am using pgadmin4 to interact with Postgres database. For now I would
> like to run 2 store procedure (those have commit statement in begin end
> block). I enable autocommit and run call 2 store procedures at the same
> time. However, there is an error with invalid transaction termination.
>
> Could you help me on this issue?
>
> Thanks,
> Trang
>

autocommit for multi call store procedure

[Trang Le]

Hi guys,

I am using pgadmin4 to interact with Postgres database. For now I would
like to run 2 store procedure (those have commit statement in begin end
block). I enable autocommit and run call 2 store procedures at the same
time. However, there is an error with invalid transaction termination.

Could you help me on this issue?

Thanks,
Trang