Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3093 closed defect (wontfix)

st_estimatedextent error with mixed case table names

Reported by: lpercich Owned by: pramsey
Priority: low Milestone: PostGIS 2.1.7
Component: postgis Version: 2.1.x
Keywords: Cc:

Description

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.

Change History (9)

comment:1 by robe, 8 years ago

Resolution: wontfix
Status: newclosed

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.

comment:2 by jef, 8 years ago

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

comment:3 by robe, 8 years ago

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.

comment:4 by lpercich, 8 years ago

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'?

comment:5 by jef, 8 years ago

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.

comment:6 by strk, 8 years ago

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

comment:7 by strk, 8 years ago

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

comment:8 by robe, 8 years ago

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.

comment:9 by jef, 8 years ago

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.

Note: See TracTickets for help on using tickets.