The PostgreSQL community is actively discussing a comprehensive set of database practices, highlighting how seemingly strict don't do this guidelines often have important nuances and exceptions. This discussion stems from a detailed PostgreSQL.org document that has sparked interesting debates about practical implementation scenarios.
The Nature of Database Guidelines
What initially appears as a list of strict prohibitions has evolved into a more nuanced discussion about contextual decision-making in database design. As one community member aptly noted:
Most of the points here are don't do it, but if you do it's not a problem. It should be renamed with Be careful about this
Timestamp Handling Controversy
The community has particularly engaged with the timestamp handling recommendations. While the official documentation strongly advocates for using timestamptz over timestamp without timezone, practitioners have highlighted practical use cases for both approaches. Some developers suggest that enforcing UTC internally while converting to local time zones for display purposes can be a valid strategy, particularly in booking systems where the recorded time zone isn't inherently relevant.
Data Type Selection Debates
The recommendations against using certain data types like char(n) and serial have generated significant discussion. Some developers challenge these guidelines, pointing out specific use cases where these types might be appropriate. For instance, while the document advises against char(n), community members have identified scenarios where char(1) could be a valid choice for very compact 1-byte fields, though this too has sparked debate about proper byte-level storage solutions.
Authentication Security Emphasis
The community strongly supports the document's stance on authentication security, particularly the warnings against using trust authentication over TCP/IP connections. This represents one of the few areas where the don't do this directive receives near-unanimous agreement, especially for production environments.
Tool Support and Implementation
The practical implementation of these guidelines has been aided by community-developed tools. Developers have pointed to linting tools that can automatically check database schemas for these potential issues, making it easier to enforce best practices systematically.
The discussion highlights how PostgreSQL best practices continue to evolve with real-world usage patterns, emphasizing the importance of understanding the reasoning behind each recommendation rather than following them blindly.
Source Citations: Don't Do This