> david.g.johnston@xxxxxxxxx wrote: > >> bryn@xxxxxxxxxxxx wrote: >> >> « >> A convention often used is to write key words in upper case and names in lower case, e.g.: >> >> UPDATE my_table SET a = 5; >> » >> >> It should be « to write key words in upper case and unquoted identifiers in lower case », yes? > > I would say: ... , and identifiers without quotes and in lower case Yes, that works. > An "identifier" is supposed to exist in the system and when you use it that existence leads you to the object that is named. search_path accepts labels that aren't true identifiers because they don't have to exist in the system. I think that you and I differ on this point. As I see things. the "identifier" notion belongs entirely to the domain of languages (like SQL and PL/pgSQL) and as such they don't "exist" anywhere except there (as notions) and then in specific language utterances (as instances of the notion). For example, just because « select * from "no such table" » causes the 42P01 error (when the identifier denotes a name that meets the expectation of its plain English reading), this doesn't mean that "no such table", qua identifier, didn't exist. After all, it exists in the SQL text where you see it. But I'll readily agree that, in most contexts of documentation and the like, the intended meaning is clear and it can be too hard (and even put off readers) always to be a stickler for the precise and correct use of terms of art. > I've enjoyed this conversation precisely because it forces me to dig deeper, think more critically, and understand the reasons behind the system's design better. Yet in terms of being able to properly use search_path to achieve a goal the couple of paragraphs in the documentation are sufficient for all practical purposes I can see. And do not, with any frequency, seem to generate questions from our users. It's a huge relief to hear this, David. I was afraid that I might be annoying you. Yes, I'll agree with your "for all practical purposes" stance—but with a caveat. There's a famous SQL injection example, beloved of bloggers, that rests on the fact that a developer didn't handle the possibility that, say, a table might have an exotic name. Then, maybe, they get the name from some metadata and build the text of a SQL statement that uses it. Because they don't know the risks, and don't have the concepts and the associated well-defined terms of art to discuss what they need to consider with themselves, they neglect to use available techniques to avoid risks. I've all too often managed to survive with a partial understanding (in any corner, using any software setting) and then managed to slip up when I stray from the typical scenarios. Just like the apocryphal developer who doesn't double-quote supposed identifies that come from some external source. That's why I strive to get the deepest possible understanding of things (and this includes "why was it done this way?"). So thank you vey much for helping me with the present particular corner of postgreSQL that's been my latest obsession. I'm ready to lay it aside now, and move on...
