st_estimatedextent error with mixed case table names

[lpercich]

issuing

select st_estimatedextent('loader','AnagraficaStrade','geom')

yields the following error:

ERROR: relation "loader.anagraficastrade" does not exist

While if I call

select st_estimatedextent('loader','"AnagraficaStrade"','geom')

I get the expected BBOX.

I would expect passing the layer name to the function without double quotes.

[robe]

I'm marking this as a wontfix. This has been the behavior for quite some time and I think fixing it for you will break it for others who assume that tables should be quoted if you want case sensitive behavior.

[jef]

Just for the table name or also for the other arguments?

[robe]

For both. We don't want to make a change in micro's that adversely affect other users used to the old behavior. Those we can consider for minor (2.2) if there is a compelling reason and it doesn't adversely affect too many people.

[lpercich]

I submitted this to the QGIS tracker, because I spotted the problem in QGIS:

​http://hub.qgis.org/issues/12478

Probably they'll hardcode the double quotes in the function call, unless you are going to change the function behaviour.

I agree with letting things the way they are, even if it is inconsistent with other PG function expecting table names and schemas as parameters.

The plus of course would be having the function accept both quoted and unquoted string arguments. There's non reason why I should call st_estimetedextent('PUBlic', 'MyTable') when looking for public.mytable: so why don't we make the function work with both '"MyTable"' and 'MyTable' or, for the lowercase name, 'mytable'?

[jef]

There might be stuff that doesn't handle camelcase specially and currently works, because camelcase is implicitly turned to lowercase when used without extra quotes on both creation and st_estimatedextent. I suppose there are also other functions that work alike.

[strk]

Is the behaviour documented ? Note that it matches behaviour of text to regclass cast

[strk]

We could maybe add a version taking a regclass, for the future...

[robe]

I like the idea of introducing regclass and yes we should document said behavior. I always avoid mixed case in Postgres so I've never thought about it much and it very well might be missing documentation as a result.

[jef]

How does this relate with #2834? Apparently the behavior already was changed earlier (and back and forth in 2.1). And in 2.0 and 2.1 triple quoting apparently makes it fail - and AFAICT in 1.5 it doesn't help either. And all that doesn't really fit with what I recall from three month ago. Odd.