 So it's a it's great to be here. My name is Matthew Radcliffe and Radcliffe on triple.org A little bit about myself. I was first introduced to the postgres SQL database management system with postgres SQL 8 Well distracting sorry I've been around the community for several years You may have seen me around at some triple cons in the North America. I was at Munich, but generally can I keep to myself? so I was first introduced with postgres SQL 8 and Doing an ERP migration from Oracle 8 in 2007. I It really informs me at that point I have to start taking into consideration other database management systems And so when I approached the Drupal module development I tried my best to support as many database management systems as possible I consider myself a hobbyist contributor when it comes to PG SQL and postgres SQL I'm not a database administrator, but I've learned a lot just with Hacking on core over the years. It is my first time to speak at a large conference. I Don't often get up to speak. I prefer to kind of sit back in the background and code but This this discussion needed to be had again, so Here we go. I'll try my best This session this core conversation is gonna Go as follows we'll briefly review the past I'll say briefly because we don't really want to get hung up on on the past situations and then detail what the Current situation is with the PG SQL driver for people who want to work on things now and And and so go over the issues and then we'll look at Reviewing options for removing from core and and then finally At that point, I'd like to open up the conversation to looking at the future of Postgres SQL and database abstraction in in future Drupal versions Here we are again, this isn't really the first time we've had this discussion Over the years, we've you know Postgres SQL has been Has worked on and off again people have it's not it doesn't satisfy the 80 20 argument of of weather of Users so the majority of users use a my SQL or my SQL like database management system We have bugs in Drupal 7 and some people consider them critical bugs enough to just not use Postgres SQL Right now unless Someone has made a commit in the last hour Postgres SQL driver is completely broken in Drupal 8 So yeah, just it's a no-go. You can't use it So the question is should we continue to support Postgres SQL? and And why should be supported if we are gonna support it and this kind of leads into database abstraction in general and Database abstraction is a is a challenge. It's hard to get right. I'm not sure if there is any Framework out there that implements database abstraction database abstraction layer perfectly And it's a challenge not just with databases, but with platforms in general And programming language standardized libraries frameworks. They're all complicated System they all have Issues that need to be solved and the cost to port or maintain, you know platforms and standardized libraries and database systems is is pretty high Sorry, I say I'm the one So frameworks database Abstraction layer makes it possible for us as developers to choose a suitable database to use for applications and Each SQL implementation as we know is uniquely powerful and implements the SQL standard in a certain way and And so many but many database abstraction layers only implement the most common concepts And so this is the first problem. It's I call it the common denominator problem and that we often see database abstraction layers going for that that database agnostic approach and This leads to the first criticism of database abstraction layers in general being that They're no good many people Not many but I jokingly say that database abstraction layers has made some people very angry and has been widely regarded as a bad move But in defense of database abstraction layers We It's not just about the You know, whether you support one system or another you have code reuse and other benefits to using a database Abstraction layer and so The common denominator or the database and agnostic approach is just one way of implementing it back in 2006 I believe we have the the four types of database abstraction layers that was defined But in a blog post One is just providing access to a database Two is providing a common interface to different software Three is actually writing portable code so that you know, you can you can make that intelligent choice And four is just is the object relational Mapping or warm or M so In our case, I would consider Drupal still type two in that our code is importable in all cases and Where it is implemented? The spec the specifications are pretty in just in general, you know, we've gone with that database agnostic approach Rails active record You know implements an ORM if you're not familiar with that Doctrine's DBL also implements an ORM so the the next issue with database abstraction layers is That and and this is very particularly to Drupal is that frameworks Implement them for a completely different reason than we implement them you know if you think about architecture and as a developer and you're you're coming up with a Solution to a problem from the ground up you're going to make those architectural decisions when developing and then choose the best tool for the job and So abstraction layers present in frameworks are really suited for that purpose there's But when you deal with Drupal, which it comes out of the box We have to think about you know, we basically were forced into thinking of things in a database agnostic approach and so Our architectural decisions are probably different than what you would get with Doctrine or rails as a framework and Finally the the third challenge of database abstraction is of course business value Is their value in having support for different systems Primary value is code reuse and it saves time To use a database abstraction layer in most cases But you know some customers want the best they can get from a system So when they're evaluating a system, they're going to say well Drupal may have performance issues because it's using database agnostic approach and thus maybe I should just go with a custom solution and For this reason we see More recently backdrop has dropped support for both PostgreSQL and SQLite and they were considering getting rid of What database abstraction layer they had in core and In and basically evaluated as such It did not have enough business value So with that in mind, I kind of you know as I researched the and I've been looking at PostgreSQL driver for a couple years I've developed my kind of my criteria for keeping PostgreSQL in core or not Or room or removing it and that is we should remove PostgreSQL driver Support from core if it provides small value to the Drupal community And if it is given low priority to fix critical and architectural issues with a storage interface And I think you know Well do is I'll approach this you know both of these these things throughout the next slides Well first let's take a kind of a look at the past and I guess Holly isn't here But I hope she's listening and she'll watch this later. So what what is PostgreSQL if you're if you are Unaware it is an ancient strict free open-source relational database management system. It's been around for decades it follows strict typing and standards and here adherence as Only an open-source database management system would do and it's free and open-source so it's It's got the PostgreSQL open-source license, which is Managed by the PostgreSQL development group, so it's it's pure open-source software Maria DB is probably the only other one other than SQLite Being in the public domain So we first got PostgreSQL in Drupal 4 and And this was of course if you're not aware of what we were doing back then we just basically had okay You can you can do queries right And then in this involved over the time over time so in Drupal 6 we got the schema API so we could then you know Provide a generic type for column Management and table management and then finally in Drupal 7 we you know We we got that the next step in database abstraction with the DB TNG and a real abstraction layer And so PostgreSQL's use use has evolved over time You know there was high hopes back in in Drupal 4 and Drupal 5 that we would start You know we'd start increasing the user base of Drupal to include PostgreSQL users but in in my mind it really has Evolved into basically a litmus test for whether In an alternative database system can be used with Drupal And that's pretty much the reason it's still in core And I'm gonna say that that test has consistently failed We know that PostgreSQL is broken or our driver is broken You know you say we failed you know Why did we fail well for one PostgreSQL is strict and so If you only test against the database system with the you know loose adoptions of Standards you're gonna run into things like the autocomplete bug and this is was present for a while in Drupal 8 If you would go to User slash autocomplete it would load the access callback For user slash percent user so the user access callback which would then Try and do a user load on the string autocomplete. This is garbage We should not be trying to load a user with this with a string identified by a string if that database Schema says it should be an integer So this was a bug in in menu get item or in the menu routing system somewhere I believe it's no longer the case in in Drupal 8 and But in our defense We have lacked the tools such as automated testing to discover these failures and fix them so It's really you know we failed but you know we really didn't give it a chance So it's kind of depressing. You know we failed whatever the current state of Drupal of the Drupal database abstraction layer is it's pretty much almost a straight port from Drupal 7 We've added some some some methods on classes we brought views in the core which deals heavily with with querying databases and then finally we've the only other changes We've abstracted storage in the way. We're a handling schema management away from the database drivers and into systems like cache and config and entities and field storage and with these things we get to how PG sequel is implementing Implementing them and the in the way is implementing them is poorly so Really we can boil that down to kind of one decision In the last couple years and that was the issue 1167144 and Is it not a bad decision? You know we decided that and the cracks of this issue was okay. We have a cache system and We don't necessarily want to always have a storage storage for that cash system In fact, why would we want to create database tables for cash if we're not going to use the database for cash? so the what what happens in in in the cache database back-end is it it will try and delete and query for for the cache and if it receives an exception it will then Try and see if it can create the table and if it's if we're using the database back-end And we're doing this in a transaction. So the the the main issue there is That postgres SQL will just roll back and stop Whereas my sequel or Oracle should we'll do implicit commits a couple other issues with our storage system is More recently this was fixed for postgres SQL, but there's a follow-up bug for SQL server We have the content entity database storage class and so we this is Another good thing we we have removed Drupal write record and that was doing you know, we've deprecated that I'm not sure if it's actually removed But it's deprecated and so they just had a lot of logic for how to handle Serial fields in in drill. So we basically if you remember dribble write record you you send it in an object just a standard class object And what would happen is we would just unset Properties and then send that to the database. So this is kind of like It's not great. You know, we want to use an entity And and call save on it and then have that go to wherever storage is necessary either config and and in the config storage system or into the content entity storage system and And so we're not handling serial fields properly and in in SQL server And to digress basically if you do an update in SQL server You cannot you put the primary keys and try and set the values of primary keys and so that that actually was we found that the the new SQL serve Module maintainer as you know found that out Just last week so we created an issue for that So the the other thing is we currently Don't have an official testing infrastructure for for postgres SQL on QA dot drip a lot of work so anything we're doing is Untested I'll get to that moment. It's not quite untested anything that the rest of core is doing is untested And also, you know, we're missing functionality because we have because we have a broken driver You know, we we're lacking things that are really cool that postgres users want and that's schema support You know, we only support the public schema We don't support a JSON type. We There's cool things that buzzers like post-GIS and we don't support that One of the reasons why you might want a schema other than public is to reduce your vulnerability for PCI compliance And just to if you're really stickler for for how you want permissions to be set up for applications accessing a database To remark on the testing infrastructure. We're making really good progress last year You know Jeremy Thorson over there Had the goal to provide test We had this goal to provide testing infrastructure for platforms languages and database systems So not just postgres SQL and SQLite, but also testing against PHP 5 3 5 4 5 5 and You know, who knows other other platforms operating systems and so Really, you know after some good progress We're you know running into difficulties because our testing infrastructure From Drupal 7 just wasn't going to cut it. So that kind of morphed into the goal of let's just re-architect our testing infrastructure Little work was lost but and so we had to start over for a postgres SQL and I think within the last three months since Austin Is that three months? four months We've we've really made some some strides there for being able to handle Different database systems in and platforms and spin things up So I kind of an exciting ground with things is yes, you can help Even if you have never used postgres SQL or SQLite before just For you know us a little straw pole here Raise your hand if you have ever participated in a core sprint Also, if you had if you have not raised your hand, I highly suggest that you come on Friday If you need any help whatsoever Core mentors, you know, we're happy to help out Raise your hand if you have worked on postgres SQL or SQLite or an alternative driver at a core sprint five people and I was gonna include his next little question, but I That I think that we'd get the same number of hands, but up until yesterday. I had never Worked on a driver issue with anybody else in the same room It can be a little depressing when you're only you're the only one working on drivers Just just because there are other issues going on other movements that have more momentum so One of the things is if you've never installed postgres SQL Or SQLite do it and get it on your development environment. I think any anyone who's working with core especially if you're reviewing things should have Have these drivers have database systems set up on their development environment and It used to be kind of difficult, you know, I don't you know, who knows how to set up postgres SQL here a lot of people, okay Well, that's not not a really good poll, but a lot of people don't you know, that's they're complete I don't know postgres SQL. So To make it easy for you and for people who don't know how to do it I you know, we have vagrant we have puppet we have you have methods of solving that problem It's solved now in the last couple of years. Thanks to the DevOps movement So I have an environment if if you want to use it It's debbie and based You know whatever I'm not a debbie and fan particularly but you know, that's kind of what I I forked off with someone else is Jubilee dev environment So with that said We have one meta issue about supporting postgres SQL and so that's that heading up there and A couple of issues the first one is just briefly Our index key length is too long So if you try and create a field that has a really long name by default Drupal is going to use the the field name is the key and So in postgres SQL it's limited to 63 characters and So if you have a really long name, it's going to do try and use it's gonna truncate it and try and possibly Try and use an index that's already already exists and you're gonna get an error So there's a path for that probably needs to be reviewed. I think that yeah the patch actually needs work You discovered yesterday doesn't pass our tests The next issue which is now in green needs to be committed is our transaction handling But this could you know, if we wanted to start thinking about the future of storage there there are follow-ups for this and the Transaction handling is all about handling the the faking out and handling implicit commits in postgres SQL So what what the patch does is it wraps all queries? That are in a transaction in a save point to emulate the behavior of my SQL Might be a little performance issues on this, but I haven't really noticed too much on on recent versions of postgres Our current status is RTBC unless someone's committing it right now They would do that wouldn't they And and the reason is so this is our current blogger if you have this patch Are the postgres SQL test spot that Ricardo Amaro is has has up on his personal site We'll reveal that we have 208 other Exceptions going on instead of not being able to find any so so this issue really is is the the first thing to solve You know other issues that are important, you know our case sensitivity on column names And again, these are some of the issues that are in the meta the next one would be the The the goal of providing test bots for everyone on the new infrastructure, so that's really important So it's not related to postgres but You know I as I was making this you know editing these slides I noticed that that we're gonna have sprints related to the test spot infrastructure and the goal of getting it all set up this week So you should probably learn more about that Jeremy and Ricardo session tomorrow at 1045 Modernizing the test spot feature triple dot org automated testing Finally, you know feature-wise if you wanted to work on non-public schemas. There's an issue for that Another issue that slipped by is is all the other drivers and it I think I think sequel I did this Maybe they they have a dummy one But the other drivers in core implemented the copy table method and this was not done in the postgres See what driver for whatever reason? the There is no reason to use copy table and core and so I think CHX has Said that we possibly could remove it But I mean it contrib might want to use it So there might be a valid reason just to implement it in postgres finally The file list view in Drupal 8 is broken because of an ambiguous column And this is not to deal with the file system, but more to do with views So there's there's an issue going on deep within views and on on when it's doing group I And it has to do with file managed and File usage if I recall correctly So this is a this is kind of exciting, you know We have we're on the brink of just having postgres SQL work for the most part And being having it testable so Let's talk about the not so distant future Drupal 8 and beyond And I think we should ask ourselves is should we continue to use postgres SQL as a litmus test For a Drupal database abstraction layer and supporting alternative drivers in triple and if it if we do want to Have it remain core. Can we actually prioritize? our driver alternative driver so they're not having to play catch up but First let's let's look at just what it would take to remove postgres for core and and maybe you know remove Moving it to contribe so One of the things that you know as a problem with Drupal is you know We're we have that database agnostic approach So we we haven't optimized our architecture for my sequel and my sequel like drivers We have PHP things in in our code. We're working around PHP quirks like No and default being different in postgres SQL We could be using my sequel specific features We could remove the hacks that are increasing our code complexity that we've added over the years and Finally, we could just start analyzing all our queries To see what we can do better for my sequel and my sequel like Such as your MariaDB. That's that's what I mean by my sequel like So backdrop CMS already did this it wasn't that hard But we have to ask ourselves a question is is when my sequel and and Maria or or the other forks start Really branching in in features What will happen then in in terms of how we support things and well, we'll probably be in a similar situation The next benefit of removing from core is that can truthfully doesn't have the same constraints as core I mean We can rewrite everything we can extend classes and in triple eight gives us his power specifically say checks Krell they worked on issue to to basically give us a mechanism for overriding storage classes So we can we can rewrite or we can extend the cash storage the entity storage the field storage all the storage and and get rid of Or redo the way that entities are saving things and You know all the contrib drivers are gonna have to do this to some extent Oracle SQL server MongoDB specifically And I think it's it probably is increasing our burden on security just because we're rewriting subsystems of Drupal And and we're just kind of we might be changing the way things are behaving But this is possible. We love alter, you know, we love to do this. I Love to do it. Is everyone else love rewriting things Extending classes. I like I've done it. I think some other cases The installer we could look at making it better and we might be hacking the installer I don't think we should do it but Again with some of the reasons why we have our transaction problems is because of the Drupal installation lastly We don't need to test all of Drupal if it's in a trip and we can focus on just testing what we need to we can Basically storage only tests take a set of queries and shove it through all the methods That we're trying to so to emulate things like The the the serial fields being set in a certain way to emulate Drupal sending an array when we should be expecting a string on our in our column definition and and this is very similar to how doctrines DBL unit tests and You know, if you're not aware of that project It you know, it has unit tests for both my sequel and postgres and sequelite And it runs about 30 minutes for for all those tests and it does my sequel about Three times and postgres about three times for various versions So the These tests are going to require infrastructure and if you're we're just in contrib We really need to have testing infrastructure Available to us to in order to test these things Maybe that means going to GitHub and then and working with Travis CI so just a risk of going down some risks of moving into contrib is is we're playing catch-up and Removing from quarry isn't going to change that. It is kind of difficult to change for that's that's up for debate The whole idea that we're supporting querying against tables that don't exist is weird It's kind of hard to change our our complete just start rethinking our storage doing that I mean that would take a lot of work in addition to maintaining a contrib driver Again, we have to work around this and decrease performance We run to the content entity database storage systems where issue where you know when you update in Postgres SQL when you update a primary key field or Sorry, just a sequence field your you want to set default sequel the sequel default type and The way you do that in PHP is different from the my sequel PHP driver and the Postgres SQL driver. So we have you know certain PHP issues And again, we might run to the same things in my sequel with my sequel later on Yeah, we're playing catch-up. So we're still gonna be playing catch-up and We're just gonna have to make more workarounds and possibly decrease performance any more So if you were using Postgres and sequel and core or sorry as a as a user Would you still use it if it was in contrib? I don't know It's gonna be more difficult to introduce things like the JSON schema type And we're gonna have to have to cooperate with a lot of contrib developers directly As they'll have to write if you wanted to have JSON storage and have a JSON field type You would have to code around the case where you install that on my sequel If you wanted to be a good contrib developer, I Don't like installing having my module fail when it's used on in different situations But yeah, you know things like post-GIS, you know, it's gonna be difficult to implement those things in contrib I in my opinion As we you know, we we don't have we're not in core and we can't provide fallbacks for other for other drivers But we know we could probably get that into contrib a lot easier And lastly, you know Moving from core would further marginalize the Postgres SQL user base. However small and it is I think, you know, we don't see many Postgres SQL users because the experience of using Postgres SQL is not great You know, I wouldn't want to use a driver that Has these issues. So I probably wouldn't install Drupal on Postgres SQL and we see that again and again as Postgres SQL enthusiasts Try install Drupal because it's supported find out that it's really it's broken in many cases and then just stop you know Stop using Postgres SQL for that project and use my sequel So this is discouraging For users, it's discouraging for for people who work on the issues. I asked You know where I was working on a core issue and I asked a Postgres SQL user friend of mine to review and he got frustrated with the whole process and use some language that I can't repeat That's that was kind of disappointing to hear from him actually So it's it's difficult to regain trust and rebuild confidence once it has been lost Just from a consumer standpoint, you usually if you have a bad experience at a restaurant, you probably don't go there again So that's all that's left are altruists and dabblers and that's That's really not gonna You're really not gonna see any there's no really need for Postgres Drupal in that case But if we want to do it, how do we get there? Well one again, it's pretty easy to remove Postgres SQL support We have the patch, but I would also like to see some responsibility taken for our failure of not supporting Postgres and Maybe a blog post or something from the Drupal Association saying hey, here's the situation We don't want to lead you into false pretenses. Here's what we're doing. We're gonna move it into contrib and Possibly help the contrib maintainers or of any database system with infrastructure and testing and Then I think we we should keep the dialogue open for a triple nine in case as we look at database abstraction And our database abstraction learning and how we're improving it and how we're approving our storage For for ideas and that that leads me to the the not so to to beyond There's been one Proposal of keeping the database agnostic driver for for tests and making it more strict and and then Basically, I think CHX came up with this proposal and then then having more performance Drivers do specific things for SQLite Postgres SQL probably not SQLite I'm not sure of what you can do there. Maybe you can pair it off with some other driver of some sort And then also for my sequel we probably you can do it. We want to do it for Percona and So this really takes into this approach was I think we first discussed right after triple con Austin and In this year And it's it's based on the our current functional QA approach So, you know, we have our simple tests and we run them run them against a database agnostic driver And that's how we do our our thing. So this would be more code to maintain but it does fit the criteria of Having you know of prioritizing our database drivers if we're gonna do that There's a there's a session about this very thing tomorrow in this room at one About the future of Drupal functional testing. So I think the when we discuss how we're how we're going to How we're gonna proceed with you with this approach it really depends on our How we're gonna proceed with testing in general Lastly we could switch to doctrine slash DBA. Oh They support more than just those three drivers They support Oracle although they only have tests for my sequel post-credits sequence of light DBL has code that's technically discouraged a lot of our patches For doing workarounds we're all Usually at first go into string replaces in reg X and we discourage that although that's up for debate because A lot of drivers do that outside Drupal And In ours in in our defense our database abstracting layer has some things that are kind of nice the transaction system the storage abstraction So it may be another approach would be to take doctrine doctrines kind of set up and split all of our drivers away from core or have you know Drupal slash DBL and then have just a specific team working on database abstraction You know this again, this is probably not for 8.1 We have to solve other issues like composer I think this this has some You know again, we have to look at what we're doing for testing for that In any case, I think you know Go go back in the future of post-credits equal rest in that it must be prioritized or else history will repeat itself We need testing infrastructure We need to be a little less selfish about our patches and taking other systems for a spin and that that's not just for progress and We need to make our database abstraction layer and storage abstraction layer more maintainable and So in my opinion if I think we're on the right track We have the initiative set up to to improve our testing infrastructure If we are prioritizing post-credits equal then then that meets my criteria, and I think it we should keep it in core But if we don't prioritize it then by all means let's let's get it Let's let's remove it. We you know if we're not going to prioritize it. Let's get it out So I would that I'd like to kind of open the conversation up and in case we want to talk about questions about post-credits sequel currently or The future of database abstraction if you want to talk about what we can do in our storage in our storage layer and If you are not busy you can fill out the session evaluation while you're at it Yes, please use the microphone so first first a couple of comments and then maybe a question Comment first in Drupal 7, you know we talked about the dismal state of the post-credits driver It is actually mostly usable with a few patches I'm one of those crazy people who has production sites in a running You know high-traffic sites running on post-credits and running quite well I've got one site in particular It's got over 20,000 nodes and it runs really really well on post-crest So don't don't think because it's not perfect and because you know the post-credits driver second certainly been a second-class citizen That it's not possible to run on post-crest at all. It is The second command is is with regards to testing I'll give you a preview of some of the things Jeremy's going to be talking about tomorrow I want to give away all the secrets But we have done a lot of work over the past three or four months to revamp the testing infrastructure I'm one of the people who signed up and said hey I want to make sure the post-crest runs better and so got got sucked into the Into the test bot world and learning things. I never thought I was going to get into but but you know we But my point there is that The only way we're going to be able to know what's the right path whether to Improve it and core or take it out of core is to measure Have a measurement of what's failing and what's not failing and and that comes back to testing So testing is obviously an important part of that So I guess my question is is a question to everybody in the room Who else is willing to step up and help do testing help? You know get get some of these issues fixed and so that we can get them committed Or or as everybody consigned to the fact that it's always going to be a second-class citizen So I'll just I'll just leave that out there for you to think about So your question is is anybody willing to in this room even with the limited number of people we have in this room went to to do a little bit more effort in their core development and take postgres sequel for a spin work on some issues and patches and Just in general You know whether we should be treating Postgres sequel as a second-class citizen and I'll start I think that if With the improvements that we're making a We probably Aren't going to be treating postgres sequel and sequel light as second second-class citizens And if we think about the future we could probably start thinking about all the database management systems as as equal Just to the to some extent Can you step up to the mic, please? And make sure I'm not I wasn't sure if the mic picked up everything that you had to say I mean I heard it, but I'm not sure if the mic picked it up. I Just wanted to say Squirrel light is a requirement for droop late. We can run tests without a skylight So it's a first-class citizen postgres is a questionable actually so I think the actually what needs the Describe the state it's a there's no Features or profit that postgre could provide Most of the there's no Big crowd around because people doesn't understand the Features the profits that what postgre could get could bring also postgre has a object model so it's a Plus one for country because we could ever write in droop late a lot of storage beckons To make them really fast for one postgre so So I I'd like to Hear a proposal any proposal how we can allow Storage driver That supports just simple operations in core to provide altering of controllers at least Providing altering of control you repeat that was you could save entity by using a variety of storage controller To reusing the storage model of postgre you can make a Clone of records So it's a different storage model for entity Right to summarize Wait when you said the first thing you mentioned was that there is little value To having postgres signal in core right now and the reason why is that one signal light? We depend a lot heavier on SQLite, so it has value to core developers I Think you know just in terms of core development. That's that's true right now. We we don't have Much value for it other than being a as I said a litmus test of what's possible But I think we we could have value in postgres SQL But again, you said you you think that it should be in contributes so we can get that value first and then as we go And I think that's perfectly a valid scenario The second thing you said was is that one of those values I think is what you said one of the values is to to use post is to be able to use postgres SQL As a document storage and a document storage model. I think actually I was talking with Damian turn so I can't pronounce his name With commerce guys and he was mentioning it. He wants to work this week on Trying to use postgres SQL as a as a dot in a kind of a document storage model By supporting the JSON This week. Yes. I yeah, I was like, oh, okay Maybe just wants to play around and and look at the possibilities if you're not familiar if we supported the You know if we had a table that stores in JSON We could do things like storing the entity, you know in JSON and then querying the properties of that JSON object. I Think maybe I I'm not too to experience with with doing queries on With the JSON type in in postgres SQL nine one, I think we're nine two But yeah, it that it has a lot of value As a end user if if we were to keep supporting that and it's a little harder to get that support in contribute in my opinion and last one think I Want to mention it's a postgres community we looks interconnected from them they very open and Wish to help Drupal to evolve driver and storage and The I need to the conference Some days ago So they said The Drupal should use object model and they wish to help So it's another resource and another value So you're talking with the with the postgres SQL community Recently and they were suggesting that we switch our whole storage model to to being document object the document object model Has its advantages. It also has its disadvantages as it's denormalized, but and the other thing you mentioned was was that the The community was offering to help us in the Drupal community accomplished that so that that is a Really cool proposal because you know in the past we you know, we know some of the comments that Some core developers have had is that where is the postgres SQL users? Why aren't they in the issues? and so It would be really awesome to see and have that discussion and and in in the issue queue about about ways we can improve Drupal for for the net, you know in as we start changing or you know As we start thinking about Drupal 9. I think that would be the appropriate Discussion there or or how we could do it in contrib I think it would take it'd be a really big module in contrived to do that So you're thinking about you know have a You know to start with maybe having keeping the core driver as he is and then then working on a Contribute I think that's great. Does anybody else interested in that one of the comment I wanted to make about about one of the the pros of not splitting You know the postgres driver often to contrib but I got thinking about was other third-party modules one of the problems I have had with with Drupal on postgres is Is not necessarily with core but there are a lot of third-party modules that that obviously don't care about anything But but my SQL and I'm afraid that if we split the driver off into a contribute module that makes other Modules say I don't have to worry about it anymore. It's not in core That's not really a you know if I write a sequel query that doesn't work on postgres I don't have to worry about that because postgres isn't in the core anymore And that's that's one thing we should also think about right so they yeah the fear There's a fear that if we remove it from core It's not going to receive the same attention from other contrived drivers and I'll counter that with examples of From the contrived space. We have MongoDB driver. We have a sequel server driver and Contrib is still open to supporting those types of Scenarios and the database systems Yeah, it's gonna depend on the contrived developer You know if you're an altruist and developer you're gonna say yeah, that's great I'll and I'll try and support it and do my best But some people will forget I mean I think that's that's I mean that's how it is for other contrived drivers So I think there's an I mean an easy answer to make it a first-class citizen right which is that the tests run on all the Supported database backends and you don't get patches committed if there's failures on any of those. I mean that's Unfortunately, I mean not having had the infrastructure has been You know preventing that I think I think in a way it's sort of like Unfortunately, it would have been an easy technical solution, especially if it had been implemented a while ago And we had it through the whole cycle But the same thing with contrived like if you Turn on test spot for contrived and all the patches are tested against all the database drivers, which should be the default than why We get a lot better. I mean as a contrived author. I've certainly Included stuff that for whatever reason broke on postgres, you know, even for a trivial reason. It's just Yeah, I'm not gonna test every single patch locally I'm postgres or even test my modules if that's not this, you know, not the stack I actually deploy on So it'd be nice just to have that automated feedback and I think that would Dramatically improve the quality of support Yeah, so I I don't think it's I Guess for me it looks I mean the the hard part is that we're in a bit of a hole until we can get to the point Where every it passed on all those all the tests passed on all those drivers and that's and that's sort of the Hard part if we got there, we would I think we would be it'd be easier to maintain There'd be relatively little friction maintaining a long run once we got to it being Supported on all and tested on all for every passport went in. I think I think the mic picked it all of that that went up so Yeah, I think that the tests having a testing infrastructure available for for all database systems is is gonna be really important going forward it just as a just for For for all the other contribute drivers as well I think that is one of the first steps to getting these other database supported And I know there is some core contributors that want it to work on these other databases because I was talking to son He was talking about having it work on other databases, so There's people in core that are interested in supporting them I think once we get that test infrastructure there Developers that want to see it happen Yeah, so yeah, there is support for using and being able to test against all database systems so yeah, I think the The important thing right now is getting that testing infrastructure finished and at least we have right now We can see what else is failing and it's fairly close to dribble seven There's some some critical issues. You probably Want to either patch out you know as drip place release I think we can continue supporting especially if we get the transaction issue committed, which it probably will be It's our TPC so It'd be great if it's before beta but So maybe a show of hands What do people think about keeping Postgres SQL in core for a Drupal 8 at least for 8.0 0.0 That's a lot of hands Maybe our population is skewed. I don't know If we Yeah, so the anybody reviewing this video could you know you probably take that into your account But the majority of the room says we should keep it in core again 8.1 Maybe if if if we're seeing That we're not really making progress. Maybe we'll remove it in 8.1 or 8.2 Probably safer for 8.2 as I think migrate comes in an 8.1 if I recall correctly or Some you know the other issue All our migrate stuff is probably broken That's another big thing. I guess that's it Thank you. I'll try to get the slides up If you want to read all the blog posts, there's a references slide with links In the last page here, but I'm not gonna bore you with bibliography