Re: R: Field's position in Table - Mailing list pgsql-general
| From | Adam Rich |
|---|---|
| Subject | Re: R: Field's position in Table |
| Date | |
| Msg-id | 536757.62031.qm@web81406.mail.mud.yahoo.com Whole thread Raw |
| In response to | Re: R: Field's position in Table (vinny <vinny@xs4all.nl>) |
| Responses |
Re: R: Field's position in Table
Re: R: Field's position in Table |
| List | pgsql-general |
For me, saying all new fields must go at the end of the table is like saying all new functions must go at the end of your C source file. Not that it makes *any* difference to the end user, or other applications using your libraries, but as developers we tend to be more organized than the general public. Most programmers habitually organize their source code to keep related functions together. It seems sloppy to have 10 memory-related functions together in the source, and then an 11th hidden 6 pages down in the middle of file-related functions. And if you're writing OO code in C++ or Java, you even group private variables and methods separately from public ones. Most of the people who advocate tacking new fields at the end of a table would never dream of following this convention for source code. So when I'm working in PgAdmin, I like to see my primary & foreign keys listed first, then data fields in logical groupings, and finally the standard "footer" fields we add to all tables like create & update by/date. Whenever I'm developing and need to reference a table definition, (or do a select * in pgAdmin for sample data) I lose productivity having to scan through all the fields repeatedly instead of seeing at a glance the fields I want because I know where they *should* be in the listing. Sometimes I have to scan through the fields several times before I finally see the one I want, because it was in the middle of unrelated items. I *never* code my applications to depend on field order; I'm referring to development convenience only. (Just my two cents, YMMV, etc) |
pgsql-general by date: