Re: Seems to be impossible to set a NULL search_path - Mailing list pgsql-general

> david.g.johnston@gmail.com wrote:
>
>> bryn@yugabyte.com 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
languageutterances (as instances of the notion). For example, just because « select * from "no such table" » causes the
42P01error (when the identifier denotes a name that meets the expectation of its plain English reading), this doesn't
meanthat "no such table", qua identifier, didn't exist. After all, it exists in the SQL text where you see it. But I'll
readilyagree that, in most contexts of documentation and the like, the intended meaning is clear and it can be too hard
(andeven 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
thereasons behind the system's design better. Yet in terms of being able to properly use search_path to achieve a goal
thecouple 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
practicalpurposes" stance—but with a caveat. There's a famous SQL injection example, beloved of bloggers, that rests on
thefact that a developer didn't handle the possibility that, say, a table might have an exotic name. Then, maybe, they
getthe name from some metadata and build the text of a SQL statement that uses it. Because they don't know the risks,
anddon'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
managedto slip up when I stray from the typical scenarios. Just like the apocryphal developer who doesn't double-quote
supposedidentifies that come from some external source. That's why I strive to get the deepest possible understanding
ofthings (and this includes "why was it done this way?"). So thank you vey much for helping me with the present
particularcorner of postgreSQL that's been my latest obsession. I'm ready to lay it aside now, and move on...