# PostgreSQL.jl no longer works in v0.6
**URL:** https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581
**Category:** Web Stack
**Created:** [July 1, 2017, 7:49am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581 "2017-07-01T07:49:22Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 1, 2017, 7:49am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/1 "2017-07-01T07:49:22Z")
Sadly, PostgreSQL.jl ([https://github.com/JuliaDB/PostgreSQL.jl](https://github.com/JuliaDB/PostgreSQL.jl)) has been lacking a maintainer for a year, and in Julia v0.6 is now dead as a dodo.
I tried updating it in various occasions but in all honesty, low-level C integration code is not my strength.
From a web developer’s perspective, _PostgreSQL is arguably the most important RDBMS_. For many years it was the only relational database offered by Heroku, for example.
_Without a powerful, up to date PostgreSQL implementation, Julia can not be taken seriously for web development._ It’s as simple as that.
Can we please do anything about it? We need a fast and modern implementation that goes beyond the hustle and the basic features of ODBC, that not only works, but also includes things like pub/sub, JSON types, etc.
1/ Is anybody looking for an OpenSource project to make a meaningful contribution? This would be a great fit - I’m happy to help with testing, documentation, etc.
2/ Can JuliaDB take this project and push it up the priority queue for an internship or a SoC project?
3/ Finally, if everything else fails, is anybody willing to do it for money? If so, message me, maybe we can gather some support in the Julia community and crowdfund the project and/or get some sponsors involved.
Any feedback on how to get this moving would be highly appreciated.
---
### Author:  [@hamoser](https://discourse.julialang.org/u/hamoser)
#### Post date: [July 2, 2017, 9:44pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/2 "2017-07-02T21:44:42Z")
@ essenciary
Thank you for raising this point. Julia’s choice of databases has been rather dismal all along, but I was willing to accept this (an generally lacking web support) as part of working in a relatively new language.
However, lack of native support for Postgres would be a complete show stopper for the projects I’m working on.
I’m in a similar position to to the OP as I my knowledge of C/C++ is not enough to take over maintenance of the driver.
However, since data used for any purpose will come out of a DB and Postgres is arguable the best FOSS DB available the lack of support in Julia is particularly troubling.
Any help with this matter would be greatly appreciated!
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 3, 2017, 11:07am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/3 "2017-07-03T11:07:38Z")
I guess the amount of feedback this issue has generated is a direct indication of the community’s interest in Postgres 🙂
Sadly, the problem is not just Postgres.
One of my responses in Genie was to speed up integration with MySQL and have that as the default as of Julia v0.6. The MySQL.jl library is much better maintained and I want to thank the contributors for that.
Although Postgres has replaced MySQL as the default DB for the web in the last years, MySQL is still strong and it’s a viable alternative until the Postgres conundrum will hopefully resolve.
But like I said, it’s not that simple. It turned out that one of the MySQL.jl most important methods, `mysql_execute` is highly type unstable. For a method that can be called even _tens of times during the duration of just one request - response cycle_ that is a very bad sign (issue opened here: [https://github.com/JuliaDB/MySQL.jl/issues/84](https://github.com/JuliaDB/MySQL.jl/issues/84))
In my opinion, the Julia core team should treat these low-level libraries as “public utilities”. They are too important to be addressed by the market (and obviously that does not work).
I don’t see many other solutions right now. For Postgres, my first thought was to get some company to sponsor the library and hire a C developer to do it right. But of course, if C developers can be found, C developers that also know Julia are a rare bird. So it looks like a vicious cycle: without libraries, developers won’t come; without developers, libraries won’t be developed. Hence the need for the Julia core team to take responsibility for these low-level libraries to help the language grow.
---
### Author:  [@lobingera](https://discourse.julialang.org/u/lobingera)
#### Post date: [July 3, 2017, 12:57pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/4 "2017-07-03T12:57:14Z")
> [@essenciary](#):
>
> In my opinion, the Julia core team should treat these low-level libraries as “public utilities”. They are too important to be addressed by the market (and obviously that does not work).
And? The list of packages which look essential to certain parts of the usage spectrum is not very short. Even if the so-called julia core team decides to do priorisation and spend own effort on packages as intrastructure, still some time will pass.
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [July 3, 2017, 1:32pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/5 "2017-07-03T13:32:46Z")
I don’t think you really need a C developer to get the package to a usable state. Most of the work should happen in Julia code. Some knowledge of C is only needed to wrap the C API, which is much less demanding than writing C code.
Also, a lot of the work probably just involves porting the package to the new Julia versions, which should not require dealing with the C wrappers (or only marginally). Fixing deprecations is typically an area where new contributors can help, as the changes are generally self-contained. Help is always welcome, as the core Julia team is already busy with stabilizing the language for 1.0.
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 3, 2017, 1:53pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/6 "2017-07-03T13:53:55Z")
And… that would be a big step ahead. It’s a matter of principle - having up-to-date, fast, feature-rich core libraries would be a major point of sale for the language, even if it takes a bit of time.
It may be that the list is long, but I think many would agree that access to major databases should be high on top of the list.
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 3, 2017, 1:58pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/7 "2017-07-03T13:58:29Z")
Like I said, it’s not only deprecations. In the specific case of Postgres, even when it worked, the library lacked features. And then, how long can we go with just patching things? Until Postgres 10?
Sure, we can all push a broken car downhill - but that’s hardly a strategy.
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 3, 2017, 2:02pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/8 "2017-07-03T14:02:42Z")
As an alternative approach, this might be a way to go, in combination with Requests:
[https://github.com/begriffs/postgrest](https://github.com/begriffs/postgrest)
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [July 3, 2017, 2:48pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/9 "2017-07-03T14:48:24Z")
> [@essenciary](#):
>
> Like I said, it’s not only deprecations. In the specific case of Postgres, even when it worked, the library lacked features. And then, how long can we go with just patching things? Until Postgres 10?
>
> Sure, we can all push a broken car downhill - but that’s hardly a strategy.
Yet the first step to get the package working again will necessarily be to fix deprecations and port it to Julia 0.6. You offered your help in the OP, so all I’m saying is that this should be doable and useful way of spending your efforts.
As in all open source projects, people have their own priorities and you have very few ways to make them work on yours. The best (and maybe only) way to help making progress in an area that interests you is to contribute, or to pay somebody to contribute for you.
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 3, 2017, 3:38pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/10 "2017-07-03T15:38:46Z")
> [@nalimilan](#):
>
> Yet the first step to get the package working again will necessarily be to fix deprecations and port it to Julia 0.6. You offered your help in the OP, so all I’m saying is that this should be doable and useful way of spending your efforts.
Yes, I actually did, but we need more specialized knowledge, for v0.6 is not as simple
>
>
> Sadly, this package is now completely broken on 0.6 :(
>
> I started patching it …but got stuck at
>
> \`\`\`julia
> ERROR: LoadError: LoadError: UndefVarError: \_IO\_FILE not defined
> Stacktrace:
> \[1\] include\_from\_node1(::String) at ./loading.jl:569
> \[2\] include(::String) at ./sysimg.jl:14
> \[3\] include\_from\_node1(::String) at ./loading.jl:569
> \[4\] eval(::Module, ::Any) at ./boot.jl:235
> \[5\] \_require(::Symbol) at ./loading.jl:483
> \[6\] require(::Symbol) at ./loading.jl:398
> while loading /Users/adrian/.julia/v0.6/PostgreSQL/src/libpq\_interface.jl, in expression starting on line 4
> while loading /Users/adrian/.julia/v0.6/PostgreSQL/src/PostgreSQL.jl, in expression starting on line 10
> \`\`\`
---
### Author:  [@jgoldfar](https://discourse.julialang.org/u/jgoldfar)
#### Post date: [July 5, 2017, 2:42am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/11 "2017-07-05T02:42:06Z")
I have some experience with v0.6, wrapping C codes and use DBMS regularly; would be interested in pitching in towards the maintenance of PostgreSQL.jl. If anyone’s interested in collaborating let me know
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [July 5, 2017, 11:00am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/12 "2017-07-05T11:00:23Z")
@jgoldfar That is amazing, thanks so much!
I’m ready to handle testing, both manually and automated, I’ve used the library extensively. Happy to try it out in my projects and update / write more tests.
I already see a bit of activity in the issue referenced above. We can continue there.
---
### Author:  [@Andreas\_Dibiasi](https://discourse.julialang.org/u/Andreas_Dibiasi)
#### Post date: [October 6, 2017, 11:30am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/13 "2017-10-06T11:30:46Z")
anything new? has somebody found the motivation to work on PostgreSQL.jl? I would be very much interested in a postgre-Julia interface.
---
### Author:  [@swt30](https://discourse.julialang.org/u/swt30)
#### Post date: [October 6, 2017, 1:12pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/14 "2017-10-06T13:12:15Z")
To get it working on 0.6 (at least for my needs) it was sufficient to just merge some pending pull requests to PostgreSQL and DBI and run femtocleaner to clean up deprecation warnings. I have forks of [PostgreSQL](https://github.com/swt30/PostgreSQL.jl) and [DBI](https://github.com/swt30/DBI.jl) if you wanted to Pkg.clone them. I make no guarantees about their suitability or stability though! (and should probably point out that my needs are pretty minimal - just running queries and fetching their results)
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [October 8, 2017, 9:47am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/15 "2017-10-08T09:47:57Z")
There was some activity but it seems that the initial enthusiasm has faded:
[https://github.com/JuliaDB/PostgreSQL.jl/pull/53](https://github.com/JuliaDB/PostgreSQL.jl/pull/53)
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [October 8, 2017, 9:51am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/16 "2017-10-08T09:51:12Z")
That’s great, I’ll give it a try!
Sadly, there aren’t many other features besides running queries, so that should cover most of the library. I would’ve loved to see pubsub support and other “exotic” features but I’m not holding my breath.
---
### Author:  [@Andreas\_Dibiasi](https://discourse.julialang.org/u/Andreas_Dibiasi)
#### Post date: [October 8, 2017, 12:30pm UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/17 "2017-10-08T12:30:52Z")
Thanks a lot. I will definitely try your forks. And, running queries and fetching their results is sufficient.
---
### Author:  [@johann.spies](https://discourse.julialang.org/u/johann.spies)
#### Post date: [October 30, 2017, 9:44am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/18 "2017-10-30T09:44:30Z")
I have logged a new issue on the original PostgreSQL.jl repository. I could not see an option to file it on your fork. If you have time, can you look into it please?
Johann
---
### Author:  [@swt30](https://discourse.julialang.org/u/swt30)
#### Post date: [October 30, 2017, 10:02am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/19 "2017-10-30T10:02:33Z")
I see the issue but unfortunately I don’t know anything about what an OID is or what kind of conversion you’d expect from it. If you can put together a minimal working example with a small sample database and query (or point me in the direction of a public database that you can reproduce the error on), we might be able to narrow down the problem.
---
### Author:  [@johann.spies](https://discourse.julialang.org/u/johann.spies)
#### Post date: [October 30, 2017, 10:27am UTC](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581/20 "2017-10-30T10:27:19Z")
Apologies, I should have investigated further. It seems that it is related to an earlier request/issue I logged:
```julia
select oid, typname from pg_type where oid = 107980182;
OID TYPE
107980182 'citext'
```
If one could adda conversion of citext → text in the code it should solve the problem. However, when I added `::text` in the query, it did not solve it.
I am to much of a Julia beginner to try and edit the PostgreSQL.jl-code myself otherwise I would have tried it.
Regards
Johann
[Next page](https://discourse.julialang.org/t/postgresql-jl-no-longer-works-in-v0-6/4581.md?page=2)