-4

Not sure of the right way to handle this. There are two meanings here,

I'm thinking we should have two options

  • sql-server-quoted-identifier for the parse option (input) in SQL-server, without which an error will be generated.
  • quote_identifier for the universal option to safely output a quoted identifier.

I went ahead and created sql-server-quoted-identifier being we have 7 questions specific to sql-server-quoted-identifier (two of them are myself). I'm open to the tag being renamed or whatever if a better more appropriate name is found but these two concepts seem discrete from my perspective.

The previous tag quoted_identifier should probably be renamed to etiher,

  • quote_identifier (to describe what people are likely to search for)
  • delimited_identifier (to describe what the spec calls the result of the function). The spec calls it a delimited_identifier but explicitly states in the grammar that the only delimiter is a the double quote. Note: Microsoft SQL's QUOTENAME (which provides this functionality) breaks the spec and produces an identifier quoted with [].

My big question moving forward is if we should put the RDBMS specific options into the system without the tie-into the RDBMS, or try to enforce a convention that place them under the RDBMS name? (rdbms-option)?

1
  • 1
    What is "quote_identifier`? A postgres thing?
    – Paul White Mod
    Jan 15, 2018 at 9:45

2 Answers 2

Reset to default
5

From the "create tags" privilege page:

When should I create new tags?

Most common tags already exist on a mature site. You should always favor existing tags; only create new tags when you feel you can make a strong case that your question does cover a new topic that nobody else has asked about before on this site.

Asking on meta was the correct approach, but your new tag idea should have been part of an answer, not part of the question. As it is, the question partly presents a fait accompli.

Neither of the quoted identifier tags is useful.

  • has no usage guidance, has been applied to only 3 questions ever, and has zero followers.

  • has been retrospectively applied to some old questions of varying quality, and a couple of new questions with negative score. It seems far too narrow to be useful. It also lacks usage guidance.

If a tag has no usage guidance, how can we expect it to be used consistently? If the creator of the tag didn't care enough to describe how it is intended to be used, why should we? If it has very few questions associated with it, what use is it? And so on.

We already have a range of tags to help with questions involving quoted identifiers, for example , , , and so on.

We do not necessarily have great canonical Q & A for each of the main types of question involving this setting, so there's an opportunity right there.

My big question moving forward is if we should put the RDBMS specific options into the system without the tie-into the RDBMS, or try to enforce a convention that place them under the RDBMS name?

Neither.

We just don't need a large number of similar super-specific tags like this, per-product or not.

Related main FAQ: Why do we tag questions?

4
  • I wouldn't use the existence of a tag-wiki as evidence for or against utility. There is a widespread need to quote identifiers. It's in the SQL spec. In order to write secure dynamic sql code that reads from the database, you have to use it. Whether or not we need a tag that identifies a common bug resulting from Microsoft wierdness is more reasonable question. I would say with 7-people coming forward -- yes. It's needed. As it identifies a very common problem arising from mundane and routine use of a product.
    – Evan Carroll
    Jan 15, 2018 at 18:17
  • I'll be happy to clean up quoted_identifiers after we pry out the Microsoft specific stuff that has nothing to do with it. I'm here because I wanted to clean it up anyway. If you want to rename it to quote_identifier or delimited_identifier. We can get started in refining it's use.
    – Evan Carroll
    Jan 15, 2018 at 18:27
  • 1
    Actually I guess that's another option too, just nuking them both. We have a tag for dynamic-sql, and sql-injection and any dynamic-sql that reads from the database needs to quote identifiers to be safe, so it seems largely redundant.
    – Evan Carroll
    Jan 15, 2018 at 18:31
  • Green lighted. =) burninante it. I would tag-synonym it to dynamic-sql.
    – Evan Carroll
    Jan 15, 2018 at 18:32
1

The setting QUOTED_IDENTIFIER is a SQL Server SET OPTION that tells the application to adhere to the ISO standard

Causes SQL Server to follow the ISO rules regarding quotation mark delimiting identifiers and literal strings. Identifiers delimited by double quotation marks can be either Transact-SQL reserved keywords or can contain characters not generally allowed by the Transact-SQL syntax rules for identifiers.

and

When SET QUOTED_IDENTIFIER is ON, identifiers can be delimited by double quotation marks, and literals must be delimited by single quotation marks. When SET QUOTED_IDENTIFIER is OFF, identifiers cannot be quoted and must follow all Transact-SQL rules for identifiers. For more information, see Database Identifiers.

and possibly

Using brackets, [ and ], to delimit identifiers is not affected by the QUOTED_IDENTIFIER setting.

Reference: SET QUOTED_IDENTIFIER (Transact-SQL)

Seeing that the tags quote_identifier and quoted_identifier and/or sql_server_quoted_identifier mean the same thing, I would refrain from creating two separate tags.

There are a group of ISO settings in Microsoft SQL Server that are controlled by a number of SET options. See the next reference for more details.

Reference:SET Statements (Transact-SQL)

1
  • Not disagreeing here, but the option has very little to do with quoting identifiers. It's a Microsoft parse option and turning it off breaks code that has no quotes inside it, every example of it being reported here is about it breaking things. CREATE TABLE f (x int, y AS (x), UNIQUE (y) ) -- what does that have to do with ANSI quoting (it fails without QUOTED_IDENTIFIER)? Microsoft may as well just have called the option stay_broken_1998 and removed any implication that was specific to ANSI quoting.
    – Evan Carroll
    Jan 15, 2018 at 18:24

You must log in to answer this question.

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