Re: [HACKERS] Casting issues with domains

2014-12-11 Thread Thomas Reiss
Le 11/12/2014 00:46, Tom Lane a écrit : > Kevin Grittner writes: >> Tom Lane wrote: >>> As far as that goes, I think the OP was unhappy about the performance >>> of the information_schema views, which in our implementation do exactly >>> that so that the exposed types of the view columns conform

Re: [HACKERS] Casting issues with domains

2014-12-10 Thread Tom Lane
Kevin Grittner writes: > Tom Lane wrote: >> As far as that goes, I think the OP was unhappy about the performance >> of the information_schema views, which in our implementation do exactly >> that so that the exposed types of the view columns conform to the SQL >> standard, even though the underl

Re: [HACKERS] Casting issues with domains

2014-12-10 Thread Kevin Grittner
Tom Lane wrote: > Kevin Grittner writes: >> It's kinda hard for me to visualize where it makes sense to define >> the original table column as the bare type but use a domain when >> referencing it in the view. > > As far as that goes, I think the OP was unhappy about the performance > of the inf

Re: [HACKERS] Casting issues with domains

2014-12-10 Thread Tom Lane
Kevin Grittner writes: > It's kinda hard for me to visualize where it makes sense to define > the original table column as the bare type but use a domain when > referencing it in the view. As far as that goes, I think the OP was unhappy about the performance of the information_schema views, which

Re: [HACKERS] Casting issues with domains

2014-12-10 Thread Kevin Grittner
Thomas Reiss wrote: > postgres=# create table test1 (a text); > CREATE TABLE > postgres=# insert into test1 select generate_series(1,10); > INSERT 0 10 > postgres=# create index idx1 on test1(a); > CREATE INDEX > postgres=# analyze test1 ; > ANALYZE; > postgres=# explain select * from tes

Re: [HACKERS] Casting issues with domains

2014-12-09 Thread Thomas Reiss
Le 08/12/2014 16:18, Tom Lane a écrit : > Thomas Reiss writes: >> postgres=# explain select * from test2 where a='toto'; >> QUERY PLAN >> -- >> Seq Scan on test1 (cost=0.00..1693.00 rows=500 width=5) >>Filter: ((

Re: [HACKERS] Casting issues with domains

2014-12-08 Thread Jim Nasby
On 12/8/14, 9:18 AM, Tom Lane wrote: The short answer is that SQL domains are not zero-cost type aliases. Perhaps there would be value in having a feature that*is* a a zero-cost alias, but it wouldn't be a domain. Note that you can actually re-use the support functions of one data type to crea

Re: [HACKERS] Casting issues with domains

2014-12-08 Thread Tom Lane
Thomas Reiss writes: > postgres=# explain select * from test2 where a='toto'; > QUERY PLAN > -- > Seq Scan on test1 (cost=0.00..1693.00 rows=500 width=5) >Filter: (((a)::tstdom)::text = 'toto'::text) > (2 lignes)

[HACKERS] Casting issues with domains

2014-12-08 Thread Thomas Reiss
Hello all, We experienced some casting issues with domains. We experienced the problem while querying the information_schema btw, but here is a simpler test case : postgres=# create table test1 (a text); CREATE TABLE postgres=# insert into test1 select generate_series(1,10); INSERT 0 10