Craig,
I know it's not what you want (Pg behaving how you expect out of the
box) but creating implicit casts to the desired types will resolve
your immediate issue. You still have to run some Pg-specific code, but
it can be restricted to your DDL where there's (presumably) already
plenty.
My
I know it's not what you want (Pg behaving how you expect out of the
box) but creating implicit casts to the desired types will resolve your
immediate issue. You still have to run some Pg-specific code, but it can
be restricted to your DDL where there's (presumably) already plenty.
See:
http:
Hello Kevin,
I strongly disagree with your analysis of this issue. Like I said, this
syntax works with 9 different databases, so obviously whatever
PosgreSQL query procesor is doing in this case is not the desired
behavior.
To ensure PosgreSQL success, the query processor must behave in a
com
Title: Signature
Hello Kevin,
My bug report is about using 'distinct' in the select list which is
causing a side-effect. That's why I classify this as a bug. Distinct
should not have unintended side-effects.
This side-effect is implementation-dependent and is manifested in the
current Postgre
On 6/4/2010 11:53 AM, Tom Lane wrote:
DISTINCT forces
the parser to assign a data type to the constants (otherwise there
is no way to understand what duplicate-elimination means) and what
it will fall back to is "text"
I am including the column list for the insert, so parser knows col2
data
>Farid Zidan wrote:
> can be eliminated by appropriately handling the distinct keyword
> and does not have to occur.
Based on previous discussions around our approaching data types, I
don't think any of the regular PostgreSQL developers are likely to
agree with you; but if you see a way to mak
>Farid Zidan wrote:
>> If we were strictly complying with the SQL standard,
> Considering the statement works in all the 9 DBMS systems+ that I
> have tested so far as mentioned above, I would say PostgreSQL is
> not compliant with SQL standard in this regard.
The SQL standard is a document
"Farid Zidan" wrote:
> insert into test_insert
> (col1, col2)
> select distinct
> 'b',
> '2010-04-30 00:00:00'
>
>
> ERROR: column "col2" is of type timestamp without time zone but
> expression is of type text
> LINE 16: '2010-04-30 00:00:00'
> ^
> HINT: You will need to rewrite or
"Farid Zidan" writes:
> If you use keyword 'distinct' for the source select of the insert statement
> the insert fails. Insert succeeds if 'distinct' is not used in select list.
This isn't a bug, it's a consequence of the fact that you're not
specifying the types of the literal constants. DISTIN
The following bug has been logged online:
Bug reference: 5490
Logged by: Farid Zidan
Email address: fa...@zidsoft.com
PostgreSQL version: 8.4.1
Operating system: Windows XP 32-bit
Description:Using distinct for select list causes insert of
timestamp string literal to
10 matches
Mail list logo