> I think this explanation is wrong --- if you run the query with EXPLAIN
> ANALYZE, you can see from the rowcounts that the writable CTE *does* get
> run to completion, as indeed is stated to be the behavior in the fine
> manual.
>
> However, for a case like this where the main query isn't readi
Kong Man writes:
> Hi Victor,
>> I see 2 problems with this query:
>> 1) CTE is just a named subquery, in your query I see no reference to
>> the upd_code CTE.
>> Therefore it is never gets called;
> So, in conclusion, my misconception about CTE in general was that all CTE get
> called without
Hi Victor,
> I see 2 problems with this query:
> 1) CTE is just a named subquery, in your query I see no reference to
> the “upd_code” CTE.
>Therefore it is never gets called;
So, in conclusion, my misconception about CTE in general was that all CTE get
called without being referenced.
Tha
2013/1/29 Kong Man :
> Can someone explain how this writable CTE works? Or does it not?
They surely do, I use this feature a lot.
Take a look at the description in the docs:
http://www.postgresql.org/docs/current/interactive/queries-with.html#QUERIES-WITH-MODIFYING
> WITH upd_code AS (
> UPDA
Can someone explain how this writable CTE works? Or does it not?
What I tried to do was to make those non-null/non-empty values of
suppliers.suppliercode unique by (1) nullifying any blank, but non-null,
suppliercode, then (2) appending the supplierid values to the suppliercode
values for tho
