On 12/18/2013 05:14 PM, John Abraham wrote:
On Dec 18, 2013, at 3:52 PM, Joe Conway wrote:
3) Not possible -- reason was given down thread. Column definition
must be known/determinable by the parser prior to query execution.
No, wait, I think you misunderstood my idea. Can’t we have a python
Hi,
Once I faced the same problem of adding new type and reqriting the query
working with crosstab function. Then I created a dynamic crosstab function.
You may have a look at it if it work out for you:
http://www.rummandba.com/2013/03/postgresql-dynamic-crosstab-function.html
Thanks.
On Tue, D
On Dec 18, 2013, at 3:52 PM, Joe Conway wrote:
>
>> 3) Can't "someone" write a pl language routine that does it better? I'd be
>> willing to work on the core
>> functionality in python if someone else would be willing to embed it in
>> plpython (I've never used plpython.)
>
> 3) Not possible
On Tue, Dec 17, 2013 at 3:31 PM, Ken Tanzer wrote:
> 1) Is there a simpler way? I'm hoping I made this unnecessarily cumbersome
> and complicated.
> 2) AFAICT, if a new unit type were to be added, I'd have to rewrite this
> query. Is there any way to avoid that?
> 3) It seems like everythin
On 12/18/2013 03:32 PM, John Abraham wrote:
Regarding crosstab, yes it's basically too complicated to use directly. Here
are the options:
1) write code (in another language, perhaps) to create your cross tab queries by
inspecting the tables, which then submits those queries to create views. W
Regarding crosstab, yes it's basically too complicated to use directly. Here
are the options:
1) write code (in another language, perhaps) to create your cross tab queries by
inspecting the tables, which then submits those queries to create views. We
have a web-app in
django/python that will
On Tue, Dec 17, 2013 at 10:42 PM, Ken Tanzer wrote:
>
> On Tue, Dec 17, 2013 at 5:11 PM, David Johnston wrote:
>>
>> 3) Limitation of SQL - explained below:
>>
>> The function call string that you pass in is just that, a string, the SQL
>> construct within which it resides has no knowledge of its
On Tue, Dec 17, 2013 at 5:11 PM, David Johnston wrote:
> 3) Limitation of SQL - explained below:
>
> The function call string that you pass in is just that, a string, the SQL
> construct within which it resides has no knowledge of its contents.
>
> SQL has the hard requirement that at the time yo
Ken Tanzer wrote
> 1) Is there a simpler way? I'm hoping I made this unnecessarily
> cumbersome and complicated.
> 2) AFAICT, if a new unit type were to be added, I'd have to rewrite this
> query. Is there any way to avoid that?
> 3) It seems like everything after the first query, except for t
On Tue, Dec 17, 2013 at 3:47 PM, rob stone wrote:
> SELECT UH.grant_number_code, UH.housing_project_code, UH. count,
> UT.description
> FROM l_unit_type UT, unit_hold UH
> WHERE UH.unit_type_code = UT.unit_type_code;
>
>
> Easier to create a view.
>
>
Thanks Rob, but that doesn't get the data in
O
n Tue, 2013-12-17 at 15:31 -0800, Ken Tanzer wrote:
>
> \d unit_hold
> Table "public.unit_hold"
> Column| Type | Modifiers
> --+---+---
> grant_number_code| character varying(10) |
> housi
Hi. I've got a simple table unit_hold, with grant numbers, buildings and
counts of unit types, which I need to summarize, along with a table listing
unit types:
\d unit_hold
Table "public.unit_hold"
Column| Type | Modifiers
--+
12 matches
Mail list logo
