From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Subject: | Re: Command Triggers |
Date: | 2011-12-11 03:26:01 |
Message-ID: | 201112110426.01570.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Peter,
On Sunday, December 04, 2011 08:01:34 PM Andres Freund wrote:
> On Sunday, December 04, 2011 05:34:44 PM Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > I have two questions now:
> > >
> > > First, does anybody think it would be worth getting rid of the
> > > duplication from OpenIntoRel (formerly from execMain.c) in regard to
> > > DefineRelation()?
> >
> > That's probably reasonable to do, since as you say it would remove the
> > opportunity for bugs-of-omission in the CTAS table creation step.
> > OTOH, if you find yourself having to make any significant changes to
> > DefineRelation, then maybe not.
> Building a CreateStmt seems to work well enough so far.
> The only problem with that approach so far that I found is that:
> CREATE TABLE collate_test2
> (
> a int,
> b text COLLATE "POSIX"
> );
>
> CREATE TABLE collate_test1
> (
> a int,
> b text COLLATE "C" NOT NULL
> );
>
> CREATE TABLE test_u AS SELECT a, b FROM collate_test1 UNION ALL SELECT a,
> b FROM collate_test2; -- fail
>
> failed with:
> ERROR: no collation was derived for column "b" with collatable type text
> HINT: Use the COLLATE clause to set the collation explicitly.
> "works" now.
Could you explain why the above should fail? After all the UNION is valid
outside the CREATE TABLE and you can even sort on b.
That tidbit is he only thing I couldn't quickly solve since the last
submission...
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2011-12-11 08:18:29 | Re: [v9.2] Fix Leaky View Problem |
Previous Message | Peter Geoghegan | 2011-12-11 01:52:59 | Re: pg_stat_statements with query tree based normalization |