and I believe we are live. Hi, Eric, how are you doing? Very
well, thanks. It's a pleasure to have you as one of our
speakers but it's also very nice to see you present about
PGMAX because I found your talk to be very didactic and very
visual. So thank you for taking the time to do a very nice
presentation. I wanted to give the opportunity as I do with
other speakers to maybe talk about some stuff that you could
not include into the talk because of the format. So is there
anything you'd like to share with the viewers that you
weren't able to include?
Oh, I think I gave most of the most of the relevant
information. This is a fairly young application. I've been
developing this since roughly the beginning of the year. So
there are probably some rough edges that people will run
into if they use Postgres differently from what I do. Or they
hear maybe conflicts with some other Emacs packages that
people use that I don't use. So I would really welcome people
trying it out and sending out bug reports if they do
encounter some. Yeah, I mean, it's usually... Go on,
please. Yeah, that would certainly help to make sure it's
nice and robust. And of course, if you're letting this loose
on some production database that you might have, you want
this to be quite robust, obviously. Yeah, indeed. Because
usually, you know, when you start publishing packages like
this, that's when you realize that it has bad interaction
with other modes in the IMAX of other persons. But
especially when you're dealing with databases, you also
realize that the domain space of what you're trying to do
with your mode also is hugely dependent on what people have
in their database, which schema they have. So, indeed, if
you have been interested, and I think plenty of people have
been interested by what you've presented, part of the
reason a software becomes great is that you've got plenty of
people making bug reports and making sure that all the
faults have been ironed out. So, you know what your task is. I
will also ask you, particularly right now, people
currently viewing, to add your questions on the pad as
usual, because you've had plenty of nice reactions, but I'm
sure you have plenty of questions as well. So Eric, what I'll
be doing, I'll be reading you the questions so that it's a
little more didactic. Starting with the first one. This is
brilliant, thank you. Do you know if PGMAX works with Tramp?
I often use Tramp multi-app to access databases both
remotely when accessing via Bastion server and locally
when using OCI containers. I believe you've already
answered but if you could just perhaps read your answer as
well for everyone to benefit from it. Yep, sure, that's my
comment indeed. So I haven't currently implemented any
Tramp support. I'm not sure that Tramp is really useful for
this type of situation, because as I understand it, Tramp is
establishing SSH connections itself to remote servers.
PGMAX is doing the same thing, so it doesn't currently have
any support for hooking in with the Tramp support. Right.
Pardon me if I missed the presentation. Oh, go on, please. I
guess you could set up an SSH tunnel. It does work with an SSH
tunnel, obviously, but there's no support for hooking into
an SSH tunnel that Tramp might be able to create. I'm not sure
Tramp actually uses SSH tunnels rather than direct
commands, but anyway. Yeah, I think that might be useful.
Yeah, I don't know either. I don't have the answer whether
Trump actually can create tunnels like this. I'm usually
used to Trump connecting to an endpoint, be it a directory or
a file, and the tunnel is just you accessing the file. But
usually, if you're trying to access a remote Postgres
database, you would probably manage the port forwarding in
a separate terminal just to be able to make sure that
everything maps correctly to your machine, and then you
would launch PGMAX with the forward port information.
That's, I assume, how you would do it anyway. But yeah, I
mean, if you could specify what you mean by TREM support and
if you have something specific in mind, I'm talking to the
questioner, feel free to specify and we'll see if you can
answer it. But in the meantime, moving to the next question.
Great work, I'm impressed. How did you come up with this
brilliant idea, I assume, to create PGMAX? Well, thanks for
the compliment. It's a lot of fun developing something
which is, as I said, such a small amount of code and which
provides quite a bit of useful functionality. In
particular, if you compare it with existing Terminal mode
applications for manipulating Postgres data, they are
not as extensible as Emacs is naturally. So I actually got
the idea for developing this when I first tested out the
SQLite mode, which is available in Emacs 29.1.
And I thought, well, that's really quite impressive. And it
allows you to delete rows and insert content and so on. And I
was thinking, yeah, Emacs is a, is a useful environment to do
that. And since several years ago, when I was doing my PhD, so
to avoid doing my PhD, I was developing Emacs, I was
developing stuff in Emacs Lisp and one of the libraries I
developed was an interface to Postgres over the network. So
that's the library called pg.el, which is used by pgmax to
access Postgres and to do all the parsing of data which
arrives in Postgres formats into the Emacs Lisp into the
Emacs corresponding versions. So, for example, integers
are passed as Emacs integers, floating point numbers as
floating point numbers, and so on. Right, yeah. I mean, it's
pretty needed, obviously, when you have such a tooling like
this, to make sure that the type conversion works properly,
because the types that you have in Postgres do not
necessarily map over to what we have in Emacs. Like, I'm
interested, how would you handle g's and b columns in PgMax?
JSON is mapped to an edis dict, a dictionary.
It depends on the top level object type for your JSON column.
If it's an array, it's mapped to an Emacs lisp array. If it's a
dict, which is most common, it's mapped to an Emacs lisp
dictionary. All right, well it makes perfect sense. So I can
break in with a question. Thanks, I just held myself to the
BBB privilege of kind of running around backstage, being a
helper backstage. So thanks for your awesome talk, Eric. I
super appreciated it. You know, I noticed that you that
you're on a slightly older version of Emacs that I deal with
in helping with producing the Windows binaries I run into
and with some other stuff I do. I'm dealing with that
friction of sometimes I've got some work of my own that
applies against a specific version of Emacs and it's a bunch
of work to think about moving it forward. Just curious if you
started thinking about that or if you routine, if that's a
routine that you haven't done or there's something maybe
specifically going on with, you know, with trunk
development that looks intimidating to deal with. Thanks
for the comment. I'm not sure I'm using a really old version
for Windows. I don't really develop often on Windows, but I I
occasionally check that it works, and I took a screenshot
that I included in the slides here, but I think I'm using
29.4, the current version on Windows. I thought I saw 29.1,
so that's probably my, I probably missed it when it went by.
My bad. No, no, I use it via the ChocoPackageUpdater so that
updates the Emacs version quite easily on Windows. So
thanks for your work on maintaining Windows binaries. I
realize that was- I sit downstream at the end of a lot of other
people's hard work and then just focus on trying to QA well
and help catch problems early. It's really fun. But of
course, my pleasure.
Coming back to the previous question, so the the
questionnaire actually provided a little more context. So
with docker.el, kubel, etc, it's often possible to, for
example, select a container pod or whatever that is hosted
on the machine you've connected to via Trump, such as
Podman, colon image colon path and trigger a terminal shell
as well as pull forward on other similar things. It'd be nice
to be able to use this tool in a similar way since it would open
up the ability to use it with complex connection
configuration. Doing SSH tunnel manually is of course
totally fine in practice and if it is actually the case
personally when I need to remote into a kubernetes machine I
use BOSIX script that I use on most of my machines but I don't
do it inside Emacs. But yeah, if such a thing is possible via
TRAMP, it definitely feels like it would be possible to do
something similar in PGMAX. So perhaps that's a path of
investigation for you that has opened up. Yeah, thanks for
these comments. I'll look into that indeed if people have
some shortcuts registered in TRAMP. So not for a terminal,
because PGMAX won't work through a terminal, but through a
port forward, then that would be convenient. I'll see how
easy that is to set up. Yeah, I'm pretty sure the way it works
is that it starts some processes in the background in eMAX
just to either maintain the port forward or to maybe remap
some kubecon things or whatever. So with PG eMAX,
considering complex pipelines to get to the end
destination, it feels like it would be possible to do
something. But perhaps it's not the responsibility of
PG-Emacs, perhaps it's the responsibility of another,
perhaps something that would target Trump more so than
PG-Emacs. But it's nice to see again how the beauty of Emacs
is that everything is Elisp at the end, and the way they
interact, you might want to question yourself whether this
belongs more to PGMAX or more to Trump, but at the end of the
day, both applications will be able to benefit from the
functions of the other. So that's the beauty of the
philosophy right here. I do see... Absolutely, I agree.
Sorry, before we move to different questions, an
additional point. I should point out that to warn people
that probably running over an SSH tunnel is going to be a bit
slow. I mostly use it on my own machine via a local Unix
connection. And for some reason that I haven't understood,
PGMAX is quite a bit slower when it's even connecting to the
same database on the local machine, but via Emacs' network
support instead of via the Unix socket support. there is
like a factor 10 difference in throughput and in latency. I
don't really understand why currently, because it's using
exactly the same Emacs Lisp level primitives. And when you
do this using other libraries like libpq, which is the
Postgres standard official library for connecting to
Postgres, there's not such a performance difference. So
there's probably something that is not working perfectly
in the Emacs network support. I'll have to see whether I can
investigate how to improve that performance. Yeah, I'm
going to say it sounds like a great bug to have because it
feels like it will allow you to dig deeper into Emacs to
understand what is going on here. Because as you said,
normally it's supposed to work exactly the same,
especially if it's still in your local machine, but it
doesn't. Personally, that's the kind of bug that I really
like and that I'd like to spend more time investigating. So
perhaps you might think otherwise, but I wish you luck on the
debugging with this particular matter. All right, moving
to the last question that we have and then we'll probably go
on a little bit of a break. Question. Is SQLite mode also
capable of all of this functionality, table relations,
etc.? If not, would it be possible to abstract out this
functionality from PGMAX somehow?
So I'm not very familiar with SQLite because I don't really
use it very much myself. I'm not sure I can answer that
question. Sorry about that. I think it is probably a bit more
basic because SQLite itself is quite a bit more basic in
terms of the types of indexes it's able to support and the
types of constraints it's able to support. Is it relevant to
create an abstract API for connecting to databases? I think
there is already actually a library that abstracts out from
SQLite and Postgres. Postgres, when you connect to it via a
PSQL subsystem,
it might be worthwhile doing that, but There are often a few
minor differences in SQL syntax and so on between
databases. So it might be difficult to have something that
really works with generic queries in an effective way. All
these SQL dialects are a little bit different,
unfortunately. So there was another question about I was
just going to read out the next question. So have you thought
about integrating your work into the Emacs tree? Do you know
if people are interested? This was a question from the past.
Yeah, I think it's probably a bit young to do so, so far.
I'm updating it quite regularly. Maybe once it's more
stabilized, I wouldn't necessarily object to this. I have
some sort of philosophical objections to giving away my
copyright, so I'm not sure that will actually be possible.
Oh, that'd be interesting. I'd love to get you on maybe a
panel talk about that sometime. Something I'd think about.
Well, from a very simple point of view, I think that the
copyright and the system works well with the existing
license and without a license transfer, so I don't feel that
the, sorry, without a copyright transfer, I don't feel that
the copyright transfer is really a necessary step for
taking things away from maintainers. It feels like Asking
the maintainers to give up on some of their corporate...
Indeed. Yeah, I see where that's a little beyond our scope,
but it's a fascinating topic and I appreciate your sharing
your views there. I mean, that sounds like a whole topic of
its own, frankly.
Yeah. Corbyn, do you want to fill the last question? Sure. So
the question was, I almost missed this one, so glad I didn't.
This may have been answered already. What do you use for
in-buffer tables? Do you use vtable? Yep. Thanks for the
question. It is indeed vtable. However, it's not really
vtable. It's a fork that I made, which is called pgmix table.
because Vtable doesn't have exactly the right
functionality in particular for recoloring rows when you
add a row. So I've currently forked this. I'm thinking about
giving those back as patches to Vtable, plausibly.
I know that there is some ongoing work also on vTable in the
core. So I'll have to look at what is plausible to feed back
into the main version.
All right, great. I think we are nearing the end of the Q&A. We
are due to move to the next talk in about three minutes now. I
can fill 30 seconds or a minute of that with I guess one more
maybe back and forth and I'll try to be quicker this time.
First of all, thanks for your kind remarks. But my question
wasn't really about Windows so much, it was just how I'm
relating So have you, let me put it more simply, have you
started looking at integrating with EMAX 30 or with the
master branch at all? Do you have any sense of how much work
it's going to be for you to carry things forward there? I've
tested it with the pre-release, yes. I mean, just a very
basic testing and everything works perfectly. There's
really no... There was no difference that I have noticed
between 29.4 and the 30 pre-release on the aspects that I use
at least in Emacs. Neato.
That was it, Leo. Thanks for letting me back in for one more
bite at the apple there. And I appreciate everybody tuning
in and participating in the Q&A and this awesome talk.
Thanks for your questions. That was great. Yeah, and thank
you for answering them and for the presentation as well. So
we'll be moving in about two minutes to the next talk, which
is pre-recorded as well. Well, we didn't really give you the
chance, Eric, to have the last word. So do you have any last
word?
please try it out, try out PGMax and send some feedback
that'll help improve it over time. Sure, great. Well, thank
you so much, Eric, for taking the time to come to the
conference, and we'll see you soon. Thank you. Bye,
everyone. Bye. And we'll be live with the next talk in about 1
minute 30. So we'll take a little bit of a breather, go make
some coffee, go take a bio break. We'll be back soon. See you
in a bit.