5

Hybrid tags have been discussed before and the consensus seems to be that they are only useful in particular cases.

I've recently found some tags that seem to be used just for problems related with a particular framework or technology when used with PostgreSQL:

might be considered as the official JDBC driver por PotsgreSQL but I could not find similar projects to justify the other tags and therefore I see no difference with just using the regular standalone tags:

What are your thoughts on this?

  • There's one specific user doing these, and he seems pretty picky about making sure that questions related to Postgres but not about Postgres promptly get their postgresql tag removed. I have to empathize with him a bit, but the creation of all those tags gets my goat. Of course, given my shtick around here, that's probably fine. – Charles Dec 18 '13 at 1:37
3

The only bad tag I see there is the , whose tag wiki states:

Use this tag for PostgreSQL issues which are to be solved in accordance with Django coding best practices.

Horsehockey.

The rest seem to be actual things, libraries, etc. doesn't have a tag wiki, and AFAIK doesn't correspond to any sort of library or other actual thing.

| improve this answer | |
1

I think one of the huge issues is that when you have all your code going through an ORM, the knowledge of the underlying database is relatively unimportant. If you want to code the rails way, then asking a PostgreSQL expert for an answer will get you an answer you don't want to use. When you are doing this with Django or the like you face similar problems. "Here's how to do it in SQL" isn't necessarily an answer that will get upvotes from users of these frameworks because it provides documentation that doesn't match the culture or expectations of the userbase. And because ORMs have their own quirks, it isn't clear to me that there is necessarily a lot of crossover.

For client libraries you have similar issues. There are a lot of questions on building and using the Pg gem, for example (and it has its own tag). Similarly we have libpq, libpqxx, etc. as tags. If we want to fold client library tags into PostgreSQL, I think we'd want to do it for all, not just PHP, JDBC, etc.

So I do see a lot of use for them because they help separate the questions regarding how to directly use the database engine from questions that don't really involve looking at this issue. If we go the other way, and want to make the PostgreSQL tag as inclusive as possible, then we need to go well beyond just the hybrid tags, and look for other related tags elsewhere that need to be folded in for consistency's sake.

EDIT

So I went and checked the Oracle tags, and on the front page of those with no answers ranked 1 or higher, there were 2 framework-specific questions. On the other hand, most of the PostgreSQL questions are framework-specific, so it isn't just that the tags are organized differently but that the sorts of questions we get are different.

| improve this answer | |
  • That's the thing though. Beyond the occasional actual connection library tag, none of the other database tags are sharded out like that. And even then, the vast majority of the questions with a connection library tag also have the master database tag. T – Charles Dec 20 '13 at 5:08
  • @Charles. I think part of it is a culture question and part of it is a use question. I doubt there are a lot of people suing Rails on Oracle and if they are, they probably know better than to tag with Oracle. On the other hand, MySQL is much more aimed at single app db's, and so you are going to get a lot more of an ORM culture there. But the question is what you do when someone asks a Hibernate question and you give an SQL answer, and they downvote because they wanted a Hibernate answer, or the same with Rails, or Django. (con't) – Chris Travers Dec 20 '13 at 5:18
  • so my question is how many of these framework-specific questions are tagged Oracle or MS SQL. – Chris Travers Dec 20 '13 at 5:18

Not the answer you're looking for? Browse other questions tagged .