proposal: alternative psql commands quit and exit

Started by Everaldo Canutoover 8 years ago138 messageshackers
Jump to latest
#1Everaldo Canuto
everaldo.canuto@gmail.com

Some of us unfortunately have to work with multiple databases like Oracle
or MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit"
to exit sql client.

Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using
"quit" and "exit" but for compatibility with psql, it also supports "\q"
and "\quit".

Postgres psql already support "\q" and "\quit" but I think that could be
cool if it supports "exit" and "quit", talking to friends I saw that I am
the only that sometimes try to exit psql with "exit'.

The attached patch implements this way to exit psql.

Regards

--
Everaldo Canuto

Attachments:

psql-exit-quit.patchapplication/octet-stream; name=psql-exit-quit.patchDownload+12-0
#2Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Everaldo Canuto (#1)
Re: proposal: alternative psql commands quit and exit

Everaldo Canuto wrote:

Some of us unfortunately have to work with multiple databases like Oracle or MySQL.
Their respective clients mysql and sqlplus uses "quit" or "exit" to exit sql client.

Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using
"quit" and "exit" but for compatibility with psql, it also supports "\q" and "\quit".

Postgres psql already support "\q" and "\quit" but I think that could be cool
if it supports "exit" and "quit", talking to friends I saw that I am the only
that sometimes try to exit psql with "exit'.
The attached patch implements this way to exit psql.

I am -1 on that, because I think that it is not good to break the simple rule
that everything that is a psql command starts with a backslash.

It might reach out to newcomers, but it will confuse people who know psql.

And frankly, anybody who has used sqlplus is used to suffering anyway.

Yours,
Laurenz Albe

In reply to: Everaldo Canuto (#1)
Re: proposal: alternative psql commands quit and exit

Why not just use ctrl+D shortcut? This EOF signal works both in bash, mysql, psql, any CLI tool which I remember

#4Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Sergei Kornilov (#3)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 5:22 AM, Sergei Kornilov <sk@zsrv.org> wrote:

Why not just use ctrl+D shortcut? This EOF signal works both in bash,
mysql, psql, any CLI tool which I remember

Because like I wrote, other sql clients also support "exit" and "quit".

#5Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Laurenz Albe (#2)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 4:00 AM, Laurenz Albe <laurenz.albe@cybertec.at>
wrote:

I am -1 on that, because I think that it is not good to break the simple
rule
that everything that is a psql command starts with a backslash.

We already have "help" command without slash and that is why I implement in
the same way help is implemented.
Also, I don't really break the rules, usual way still works, I just added
an alternative way.

It might reach out to newcomers, but it will confuse people who know psql.

For people already know psql nothing is changed, we will just have a hidden
way to exit.

I just think that if it don't change or break anything for usual psql user
but also help some new comers, then is good.

And remember, mysql client implement "\q" and "\quit" just to be more
friendly to psql users. Lets us be friendly too ;-)

Regards

#6Michael Paquier
michael@paquier.xyz
In reply to: Everaldo Canuto (#5)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 7:06 PM, Everaldo Canuto
<everaldo.canuto@gmail.com> wrote:

For people already know psql nothing is changed, we will just have a hidden
way to exit.

I just think that if it don't change or break anything for usual psql user
but also help some new comers, then is good.

And remember, mysql client implement "\q" and "\quit" just to be more
friendly to psql users. Lets us be friendly too ;-)

I think that you are going to need better reasons than just being more
friendly with other database clients by breaking a rule which is
around for 20 years. For one, it seems to me that your patch is
breaking multi-line SQL support with psql, as "quit" or "exit" are
legit SQL object names.
--
Michael

#7Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Michael Paquier (#6)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 8:10 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:

I think that you are going to need better reasons than just being more
friendly with other database clients by breaking a rule which is
around for 20 years.

Well, that reason was enough for other sql clients to implement "\q" and
"\quit" even if they don't use "\" commands.
Note that we are not breaking a rule, we already have "help" without slash
and as I said, "slash way" still supported and still oficial way to exit.

For one, it seems to me that your patch is
breaking multi-line SQL support with psql, as "quit" or "exit" are
legit SQL object names.

No, it is not breaking. Did you test it? My patch takes care of multi-line
commands. Look at second line of patch:

pset.cur_cmd_interactive && query_buf->len == 0

Line 4 also take care about other possible problems:

(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))

I know that this "feature" don't make any difference for most of you guys
but also it will not hurt anyone and will help a little for newcomers and
people that uses different sql clients. To be honest. I could understand
that is not a good idea to accept patches like this if it is too big since
it could make things hard to maintainers but honestly, this patch is very
small and trivial.

Regards.

#8Nikolay Samokhvalov
samokhvalov@gmail.com
In reply to: Michael Paquier (#6)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 2:10 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:

I think that you are going to need better reasons than just being more
friendly with other database clients ...

This is not about other database clients. This is about users considering
migration to Postgres.
People!

I'm definitely +1 for this, I've seen many people struggling because of
this. Being more friendly to new users = more users in future.

At least "quit" and "exit" might be aliases for "help".

#9Daniel Verite
daniel@manitou-mail.org
In reply to: Everaldo Canuto (#1)
Re: proposal: alternative psql commands quit and exit

Everaldo Canuto wrote:

Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using
"quit" and "exit" but for compatibility with psql, it also supports "\q"
and "\quit".

When looking at the most popular postgres questions on stackoverflow:

https://stackoverflow.com/questions/tagged/postgresql?sort=votes

the first one (most up-voted) happens to be:

"How to exit from PostgreSQL command line utility: psql"

now at 430k views and 1368 upvotes.

Independently of the syntax-compatibility with other tools,
it can be a miserable experience for people who almost
never use psql to type "quit" or "exit" after they're done
with whatever they wanted to do, and nothing
happens except a tiny change in the prompt.

Implementing it is easy, but it might be a hard sell for the project
because it creates a precedent.
The next question in that list is "PostgreSQL DESCRIBE TABLE", so
why not implement "desc tablename;" as a synonym for
"\d tablename"?

The question after that is "Show tables in PostgreSQL", so
why not implement "show tablename;"? Well, this one is
impossible because SHOW is already a SQL command that does
something else, so that's already the end of that road to
compatibility.

Personally I'm +1 on accepting the additional "exit" and "quit"
as synonyms for \q, to comply with the "Do What I Mean" UX rule,
rather than just compatibility with other tools.
I guess this is why "help" is already a synonym of \h.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

#10Ryan Murphy
ryanfmurphy@gmail.com
In reply to: Daniel Verite (#9)
Re: proposal: alternative psql commands quit and exit

I am +1 on doing this too, unless we can imagine it clashing with any SQL
queries or breaking scripts (which I can't).

Helping people migrate to postgres w minimal frustration is important
enough imho to be worth breaking this \ rule unless we can forsee real
actual compatibility problems. We already have "help", so it's not like we
have literally 0 commands that don't start with \.

Best,
Ryan

#11Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Daniel Verite (#9)
Re: proposal: alternative psql commands quit and exit

Hello,

On Fri, Dec 8, 2017 at 11:57 AM, Daniel Vérité" <daniel@manitou-mail.org>
wrote:

Implementing it is easy, but it might be a hard sell for the project
because it creates a precedent.

We already have "help" (without slash) so I don't think it is a precedent.

The next question in that list is "PostgreSQL DESCRIBE TABLE", so
why not implement "desc tablename;" as a synonym for
"\d tablename"?

I must be honest to you, I create this small patch to see how is contribute
do Postgres and to check how is reception on Postgres community.
That said, DESC[RIBE] is on my list for next patches but it is not a
synonym to \d.

DESC[RIBE] must be a SQL command, very useful when you are not running
psql. But let us discuss this on another thread ;-)

The question after that is "Show tables in PostgreSQL", so
why not implement "show tablename;"? Well, this one is
impossible because SHOW is already a SQL command that does
something else, so that's already the end of that road to
compatibility.

Didn't know about SHOW command. Are TABLES a reserved word?

Regards.

#12Oliver Ford
ojford@gmail.com
In reply to: Everaldo Canuto (#1)
Re: proposal: alternative psql commands quit and exit

On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto
<everaldo.canuto@gmail.com> wrote:

Some of us unfortunately have to work with multiple databases like Oracle or
MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit" to
exit sql client.

Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using
"quit" and "exit" but for compatibility with psql, it also supports "\q" and
"\quit".

Postgres psql already support "\q" and "\quit" but I think that could be
cool if it supports "exit" and "quit", talking to friends I saw that I am
the only that sometimes try to exit psql with "exit'.

+1 from me. When I first used Postgres I struggled with how to quit
psql. I felt that making people look up how to quit the program is bad
UI design. I admired Postgres as a database, but had the impression
that it was harder to use than MySQL. Not being able to quit or
describe a table in the way I was used to was frustrating.

If anyone is unsure on this point, I'd recommend reading Joel
Spolsky's articles on UI design. He clearly explains how a program
model should match a user model. The fact that it's always been done
this way is irrelevant to new users, who want a db that is intuitive.

#13David G. Johnston
david.g.johnston@gmail.com
In reply to: Everaldo Canuto (#11)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 7:26 AM, Everaldo Canuto <everaldo.canuto@gmail.com>
wrote:

Didn't know about SHOW command. Are TABLES a reserved word?

​There isn't going to be that much appetite for this just so that people
can use PostgreSQL without reading our documentation: or the output of
typing "help" at the psql prompt that says "type \q to quit".​

I don't know how one would go about reasonably writing extensions for psql
but that, to me, would be the preferred approach. Then people could
install whichever compatability module they'd like.

I'll agree that exiting the program is a special case that merits
consideration - and it has been given that in the form of the concession to
the word "help" in order to get the reader unfamiliar with our backslash
prefix a non-backslash way to obtain that knowledge apart from reading our
docs. Under that premise I would accept (lacking compelling arguments for
why its a bad idea) this proposal for quit/exit but am against anything
beyond that.

David J.

#14Ryan Murphy
ryanfmurphy@gmail.com
In reply to: David G. Johnston (#13)
Re: proposal: alternative psql commands quit and exit

​There isn't going to be that much appetite for this just so that people
can use PostgreSQL without reading our documentation: or the output of
typing "help" at the psql prompt that says "type \q to quit".​

Agree with this. The whole reason people here are reluctant to add "quit"
in the first place is that it could become a slippery slope where people
now want every popular MySQL/Oracle command cloned, just so they can avoid
reading docs and never understand the design/power/elegance of Postgres.

For example, while I think "quit" is a good idea, it'd be a shame if it
caused people to never find out about \ commands.

I'll agree that exiting the program is a special case that merits

consideration

Yes, I think we can find the right balance here. We don't need to suddenly
start implementing SHOW TABLES, as attractive as that is to people who know
MySQL.

#15David G. Johnston
david.g.johnston@gmail.com
In reply to: Oliver Ford (#12)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 7:34 AM, Oliver Ford <ojford@gmail.com> wrote:

On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto
<everaldo.canuto@gmail.com> wrote:

+1 from me. When I first used Postgres I struggled with how to quit
psql. I felt that making people look up how to quit the program is bad
UI design. I admired Postgres as a database, but had the impression
that it was harder to use than MySQL.

Not being able to quit or
describe a table in the way I was used to was frustrating.

​Whomever comes second is almost always going to have that problem.

who want a db that is intuitive.

​Intuitive and "works like xyz" are not the same thing ...

If you want to argue that "prefixing commands with a backslash" is not
intuitive then fine - though in a program where most of the stuff I write
is meant to be sent to the server for interpretation knowing that if I
place a backslash in front of it I will instead have the subsequent text
interpreted locally, while not "intuitive", is obvious and consistent once
I've learned the rule. That it also allows for mixing server and client
targeted text further reinforces that boon. Having both backslash and
non-backslash ways to done something just puts more information into my
head that I need to sift through when learning the program.

Pretty much every interactive shell program in existence needs an exit/quit
command so flexing here to match the most common, and used in every
session, command seems worthwhile to me. Creating non-backslash variants
of every psql command that exists does not (and many wouldn't make sense or
work anyways). Because of that I'd be inclined to be internally consistent
and mandate backslash for everything and understand that it does add a
small grade to the learning curve for those coming from other database
clients. Refraining from making our client more complex to learn for the
first-time db user seems more important than making it so experienced db
users don't have to learn certain parts at all.

David J.

#16David G. Johnston
david.g.johnston@gmail.com
In reply to: Ryan Murphy (#14)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 8:09 AM, Ryan Murphy <ryanfmurphy@gmail.com> wrote:

​There isn't going to be that much appetite for this just so that people

can use PostgreSQL without reading our documentation: or the output of
typing "help" at the psql prompt that says "type \q to quit".​

For example, while I think "quit" is a good idea, it'd be a shame if it

caused people to never find out about \ commands.

​I suppose the only bad thing about introducing "exit"​, which itself seems
like the more common choice for program stopping command, is that someone
might end up inferring that "\e" should work to exit the program instead of
opening an editor...

David J.

#17Tom Lane
tgl@sss.pgh.pa.us
In reply to: David G. Johnston (#13)
Re: proposal: alternative psql commands quit and exit

"David G. Johnston" <david.g.johnston@gmail.com> writes:

I'll agree that exiting the program is a special case that merits
consideration - and it has been given that in the form of the concession to
the word "help" in order to get the reader unfamiliar with our backslash
prefix a non-backslash way to obtain that knowledge apart from reading our
docs. Under that premise I would accept (lacking compelling arguments for
why its a bad idea) this proposal for quit/exit but am against anything
beyond that.

Meh. I never thought that the "help" business was particularly well
thought out, and this proposal isn't better. The reason is that to
avoid breaking multi-line SQL command entry, we can only accept such
a command when the input buffer is empty. A psql novice is unlikely
to be familiar with that concept, let alone know that \r or ^C is the
way to get there. There's a weak argument that "help" is of some
value because it's likely to be the first thing a novice types, but
that doesn't apply for quit/exit. The typical interaction I'd foresee
is more like

postgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exit

with nothing accomplished except to increase the user's frustration
each time. Eventually she'll hit on ^D and get out of it, but none
of these allegedly novice-friendly "features" helped at all.

regards, tom lane

#18Szymon Guz
mabewlun@gmail.com
In reply to: Oliver Ford (#12)
Re: proposal: alternative psql commands quit and exit

On 8 December 2017 at 15:34, Oliver Ford <ojford@gmail.com> wrote:

On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto
<everaldo.canuto@gmail.com> wrote:

Some of us unfortunately have to work with multiple databases like

Oracle or

MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit"

to

exit sql client.

Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited

using

"quit" and "exit" but for compatibility with psql, it also supports "\q"

and

"\quit".

Postgres psql already support "\q" and "\quit" but I think that could be
cool if it supports "exit" and "quit", talking to friends I saw that I am
the only that sometimes try to exit psql with "exit'.

+1 from me. When I first used Postgres I struggled with how to quit
psql. I felt that making people look up how to quit the program is bad
UI design. I admired Postgres as a database, but had the impression
that it was harder to use than MySQL. Not being able to quit or
describe a table in the way I was used to was frustrating.

If anyone is unsure on this point, I'd recommend reading Joel
Spolsky's articles on UI design. He clearly explains how a program
model should match a user model. The fact that it's always been done
this way is irrelevant to new users, who want a db that is intuitive.

Well, if I have a new program I usually read some documentation. It really
helps people to exit vim as well :)

Thinking this way for me psql's way is the intuitive one, because I know it.
Should I kindly ask Oracle to change their programs because I rather want
to use their software than reading their documentation?

regards
Szymon Lipiński

#19David G. Johnston
david.g.johnston@gmail.com
In reply to: Tom Lane (#17)
Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 8:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:
A psql novice is unlikely
to be familiar with that concept, let alone know that \r or ^C is the
way to get there. There's a weak argument that "help" is of some
value because it's likely to be the first thing a novice types, but
that doesn't apply for quit/exit. The typical interaction I'd foresee
is more like

postgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exit

with nothing accomplished except to increase the user's frustration
each time. Eventually she'll hit on ^D and get out of it, but none
of these allegedly novice-friendly "features" helped at all.

​help -> exit -> (they may think of "quit" ...)​

My major CLI experience is bash and for this I use "exit", and in Windows
you go to "File -> Exit". Quit makes sense but exit is more common. I'm
inclined to buy into this proposal for that reason alone. The usage
problem you demonstrate is only somewhat valid since the level of
frustration depends on whether they are just tying commands or know from
the docs that "quit" is supposed to work. And even backslash commands
won't work if you leaving the session in the middle of text literal. So,
I'll agree but all of the mitigation above means I don't think this
proposal makes the situation much (if at all) worse if they aren't reading
the docs and can be lessened if they are.

David J.

#20Vladimir Svedov
vodevsh@gmail.com
In reply to: Tom Lane (#17)
Re: proposal: alternative psql commands quit and exit

I wonder if *exit;* to terminate loop be confused with exit psql in case of
bad syntax. then instead of reporting error in plpgsql it would just
silently exit?..

2017-12-08 15:19 GMT+00:00 Tom Lane <tgl@sss.pgh.pa.us>:

Show quoted text

"David G. Johnston" <david.g.johnston@gmail.com> writes:

I'll agree that exiting the program is a special case that merits
consideration - and it has been given that in the form of the concession

to

the word "help" in order to get the reader unfamiliar with our backslash
prefix a non-backslash way to obtain that knowledge apart from reading

our

docs. Under that premise I would accept (lacking compelling arguments

for

why its a bad idea) this proposal for quit/exit but am against anything
beyond that.

Meh. I never thought that the "help" business was particularly well
thought out, and this proposal isn't better. The reason is that to
avoid breaking multi-line SQL command entry, we can only accept such
a command when the input buffer is empty. A psql novice is unlikely
to be familiar with that concept, let alone know that \r or ^C is the
way to get there. There's a weak argument that "help" is of some
value because it's likely to be the first thing a novice types, but
that doesn't apply for quit/exit. The typical interaction I'd foresee
is more like

postgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exit

with nothing accomplished except to increase the user's frustration
each time. Eventually she'll hit on ^D and get out of it, but none
of these allegedly novice-friendly "features" helped at all.

regards, tom lane

#21Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Vladimir Svedov (#20)
#22Oliver Ford
ojford@gmail.com
In reply to: David G. Johnston (#15)
#23Robert Haas
robertmhaas@gmail.com
In reply to: Daniel Verite (#9)
#24Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#23)
#25hvjunk
hvjunk@gmail.com
In reply to: Robert Haas (#23)
#26Robert Haas
robertmhaas@gmail.com
In reply to: Szymon Guz (#18)
#27Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#24)
#28Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#27)
#29Michael Paquier
michael@paquier.xyz
In reply to: Robert Haas (#23)
#30Rok Kralj
rok.kralj@gmail.com
In reply to: Michael Paquier (#29)
#31Daniel Verite
daniel@manitou-mail.org
In reply to: Tom Lane (#17)
#32Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Daniel Verite (#31)
#33Scott Mead
scottm@openscg.com
In reply to: Rok Kralj (#30)
#34Daniel Verite
daniel@manitou-mail.org
In reply to: Everaldo Canuto (#32)
#35David Fetter
david@fetter.org
In reply to: Robert Haas (#26)
#36Peter Eisentraut
peter_e@gmx.net
In reply to: hvjunk (#25)
#37Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#17)
#38hvjunk
hvjunk@gmail.com
In reply to: Peter Eisentraut (#37)
#39Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#37)
#40Fabrízio de Royes Mello
fabriziomello@gmail.com
In reply to: David Fetter (#35)
#41Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Fabrízio de Royes Mello (#40)
#42David Fetter
david@fetter.org
In reply to: Fabrízio de Royes Mello (#40)
#43Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#39)
#44Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#43)
#45Chapman Flack
chap@anastigmatix.net
In reply to: Tom Lane (#44)
#46Craig Ringer
craig@2ndquadrant.com
In reply to: Chapman Flack (#45)
#47Craig Ringer
craig@2ndquadrant.com
In reply to: Tom Lane (#44)
#48Tom Lane
tgl@sss.pgh.pa.us
In reply to: Craig Ringer (#46)
#49Craig Ringer
craig@2ndquadrant.com
In reply to: Tom Lane (#48)
#50Gasper Zejn
zejn@owca.info
In reply to: Tom Lane (#48)
#51Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Daniel Verite (#9)
#52Jeremy Finzel
finzelj@gmail.com
In reply to: Gasper Zejn (#50)
#53David G. Johnston
david.g.johnston@gmail.com
In reply to: Jeremy Finzel (#52)
#54Avinash Kumar
avinash.vallarapu@gmail.com
In reply to: David G. Johnston (#53)
#55Arthur Nascimento
tureba@gmail.com
In reply to: Jeremy Finzel (#52)
#56Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Geoff Winkless (#51)
#57Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Everaldo Canuto (#56)
#58Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Everaldo Canuto (#56)
#59Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Arthur Nascimento (#55)
#60Chapman Flack
chap@anastigmatix.net
In reply to: Geoff Winkless (#59)
#61Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Chapman Flack (#60)
#62Robert Haas
robertmhaas@gmail.com
In reply to: Geoff Winkless (#51)
#63Robert Haas
robertmhaas@gmail.com
In reply to: Everaldo Canuto (#58)
#64Robert Haas
robertmhaas@gmail.com
In reply to: Geoff Winkless (#61)
#65Chapman Flack
chap@anastigmatix.net
In reply to: Robert Haas (#62)
#66Michael Paquier
michael@paquier.xyz
In reply to: Robert Haas (#63)
#67Craig Ringer
craig@2ndquadrant.com
In reply to: Geoff Winkless (#51)
#68Craig Ringer
craig@2ndquadrant.com
In reply to: Avinash Kumar (#54)
#69David G. Johnston
david.g.johnston@gmail.com
In reply to: Craig Ringer (#67)
#70Chapman Flack
chap@anastigmatix.net
In reply to: Robert Haas (#64)
#71Tom Lane
tgl@sss.pgh.pa.us
In reply to: Chapman Flack (#70)
#72Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Everaldo Canuto (#1)
#73Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Everaldo Canuto (#72)
#74Vik Fearing
vik@postgresfriends.org
In reply to: Alvaro Herrera (#73)
#75Stephen Frost
sfrost@snowman.net
In reply to: Vik Fearing (#74)
#76Vik Fearing
vik@postgresfriends.org
In reply to: Stephen Frost (#75)
#77Stephen Frost
sfrost@snowman.net
In reply to: Vik Fearing (#76)
#78Tom Lane
tgl@sss.pgh.pa.us
In reply to: Vik Fearing (#76)
#79Stephen Frost
sfrost@snowman.net
In reply to: Tom Lane (#78)
#80Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Tom Lane (#78)
#81Chapman Flack
chap@anastigmatix.net
In reply to: Everaldo Canuto (#80)
#82Everaldo Canuto
everaldo.canuto@gmail.com
In reply to: Chapman Flack (#81)
#83Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Everaldo Canuto (#82)
#84Robert Haas
robertmhaas@gmail.com
In reply to: Laurenz Albe (#83)
#85Stephen Frost
sfrost@snowman.net
In reply to: Robert Haas (#84)
#86Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#84)
#87Robert Haas
robertmhaas@gmail.com
In reply to: Stephen Frost (#85)
#88Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#86)
#89Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Robert Haas (#88)
#90Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Geoff Winkless (#89)
#91Stephen Frost
sfrost@snowman.net
In reply to: Geoff Winkless (#89)
#92Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Laurenz Albe (#90)
#93Tom Lane
tgl@sss.pgh.pa.us
In reply to: Geoff Winkless (#92)
#94Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Tom Lane (#93)
#95Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#88)
#96David Fetter
david@fetter.org
In reply to: Geoff Winkless (#94)
#97Tom Lane
tgl@sss.pgh.pa.us
In reply to: Geoff Winkless (#94)
#98Geoff Winkless
pgsqladmin@geoff.dj
In reply to: David Fetter (#96)
#99Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Tom Lane (#97)
#100Tom Lane
tgl@sss.pgh.pa.us
In reply to: Geoff Winkless (#99)
#101Chapman Flack
chap@anastigmatix.net
In reply to: David Fetter (#96)
#102Tels
nospam-pg-abuse@bloodgate.com
In reply to: Robert Haas (#88)
#103Tels
nospam-pg-abuse@bloodgate.com
In reply to: Tels (#102)
#104David Fetter
david@fetter.org
In reply to: Chapman Flack (#101)
#105Chapman Flack
chap@anastigmatix.net
In reply to: David Fetter (#104)
#106Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Tom Lane (#100)
#107Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#95)
#108Robert Haas
robertmhaas@gmail.com
In reply to: Geoff Winkless (#106)
#109Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#107)
#110Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Tom Lane (#109)
#111Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Robert Haas (#108)
#112Chapman Flack
chap@anastigmatix.net
In reply to: Geoff Winkless (#111)
#113Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Chapman Flack (#112)
#114Tom Lane
tgl@sss.pgh.pa.us
In reply to: Chapman Flack (#112)
#115Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Tom Lane (#114)
#116Robert Haas
robertmhaas@gmail.com
In reply to: Geoff Winkless (#115)
#117Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Robert Haas (#116)
#118Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Geoff Winkless (#115)
#119KAWAMICHI Ryoji
kawamichi@tkl.iis.u-tokyo.ac.jp
In reply to: Robert Haas (#84)
#120Vik Fearing
vik@postgresfriends.org
In reply to: KAWAMICHI Ryoji (#119)
#121Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Vik Fearing (#120)
#122Geoff Winkless
pgsqladmin@geoff.dj
In reply to: Alvaro Herrera (#121)
#123Bruce Momjian
bruce@momjian.us
In reply to: Robert Haas (#88)
#124Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#123)
#125Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#124)
#126Daniel Verite
daniel@manitou-mail.org
In reply to: Bruce Momjian (#124)
#127Bruce Momjian
bruce@momjian.us
In reply to: Daniel Verite (#126)
#128Bruce Momjian
bruce@momjian.us
In reply to: Daniel Verite (#126)
#129Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#125)
#130Bruce Momjian
bruce@momjian.us
In reply to: Daniel Verite (#126)
#131Daniel Verite
daniel@manitou-mail.org
In reply to: Bruce Momjian (#128)
#132Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#127)
#133Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#132)
#134Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#133)
#135Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#134)
#136Michael Paquier
michael@paquier.xyz
In reply to: Bruce Momjian (#135)
#137Bruce Momjian
bruce@momjian.us
In reply to: Michael Paquier (#136)
#138Ivan E. Panchenko
i.panchenko@postgrespro.ru
In reply to: Bruce Momjian (#137)