Re: nvarchar notation accepted?
От | Peter Eisentraut |
---|---|
Тема | Re: nvarchar notation accepted? |
Дата | |
Msg-id | 1275895438.1849.1.camel@fsopti579.F-Secure.com обсуждение исходный текст |
Ответ на | Re: nvarchar notation accepted? (Jaime Casanova <jaime@2ndquadrant.com>) |
Ответы |
Re: nvarchar notation accepted?
|
Список | pgsql-hackers |
On sön, 2010-06-06 at 21:13 -0500, Jaime Casanova wrote: > On Thu, May 13, 2010 at 11:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Jaime Casanova <jaime@2ndquadrant.com> writes: > >> On Thu, May 13, 2010 at 10:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> Actually, the lexer translates N'foo' to NCHAR 'foo' and then the > >>> grammar treats that just like CHAR 'foo'. In short, the N doesn't do > >>> anything very useful, and it certainly doesn't have any effect on > >>> encoding behavior. I think this is something Tom Lockhart put in ten or > >>> so years back, and never got as far as making it actually do anything > >>> helpful. > > > >> so, the N'' syntax is fine and i don't need to hunt them as a migration step? > > > > As long as the implied cast to char(n) doesn't cause you problems, it's > > fine. > > > > Is this something we want to document? Maybe something like: > """ > For historical reasons N'' syntax is also accepted as a string literal. > """ > > or we can even mention the fact that that is useful for sql server migrations? I don't think it's a historical reason, at least not unless all reasons are to some degree historical. The N'' syntax is in the SQL standard, and so if our implementation matches that, it should be documented as a supported feature, and if it doesn't match it, we should fix it, and perhaps leave it undocumented until we have figured out what we want it to do. (I have not done that analysis.)
В списке pgsql-hackers по дате отправления: