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
see no technical analysis in your response. If you too busy to engage
in logical debate, you should remove yourself from the bug list.
Software is built on logical analysis. You are too busy, do not participate.
Farid
On 6/5/2010 4:16 PM, Dimitri Fontaine wrote:
Farid Zidan writes:
I am
ing literal
being inserted into col2 whose data type is timestamp, perfectly safe.
Farid
On 6/5/2010 3:26 AM, Craig Ringer wrote:
On 05/06/10 06:15, Farid Zidan wrote:
insert into test_insert
(col1, col2)
select *distinct*
'b',
'2010-04-30 00:00:00'
keyword in step 1, 2 and conversion from string
literal to timestamp value in step 3
There is no ambiguity or magic to happen. Obviously in PG case there is
some design or fault somewhere in this use-case when distinct keyword
is used and is processed in step 2, that's all.
Farid
On 6/4/2010 10:41
w, but that would be nice otherwise user will
see a bunch of one-time errors and lose some ease of use but otherwise
will not be too badly affected.
Farid
On 6/4/2010 9:42 PM, Kris Jurka wrote:
On Fri, 4 Jun 2010, Farid Zidan wrote:
Here is actual statements I am running and
like I said
Title: Signature
Hello Kevin,
I can't help but wonder why you resist using the standard syntax.
I am using the standard syntax. Single quote in sql denotes a string.
so '2010-04-30 00:00:00' is string literal. That's universal. Now you
want me to use PG-specific timestamps and that's l
PostreSQL is doing
the first part (subquery with distinct clause correctly), but when it
gets to use the resultset of the subquery in the insert it "forgets"
how to convert
'2010-04-30 00:00:00' to timestamp value (but forgets only when
'distinct' is used in the
I am sure it can impact other developers projects and it
would need to be addressed at
some point in the future with a solution where it just work like it
does in all the other DBMSs.
Farid
On 6/4/2010 1:36 PM, Kevin Grittner wrote:
Farid Zidan wrote:
can be elimin
causing the error.
Farid
On 6/4/2010 12:52 PM, Kevin Grittner wrote:
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 men
that's what needs to be fixed to ensure PostgreSQL
compatibility with SQL standard and interoperability with generic sql
statements.
best regards,
Farid
On 6/4/2010 11:57 AM, Kevin Grittner wrote:
"Farid Zidan" wrote:
insert into test_insert
(col1, col2)
select disti
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
The following bug has been logged online:
Bug reference: 1423
Logged by: Farid Zidan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2000
Description:ODBC SQLTables SQL_ALL_CATALOGS and SQL_ALL_SCHEMAS
options don't work
De
The following bug has been logged online:
Bug reference: 1422
Logged by: Farid Zidan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2
Description:ODBC SQLTables SQL_ALL_TABLE_TYPES no resultset
Details:
::SQLTables( hstmt
The following bug has been logged online:
Bug reference: 1415
Logged by: Farid Zidan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2000
Description:odbc driver SQLGetInfo SQL_CATALOG_TERM returns empty
string
Details:
odbc
14 matches
Mail list logo
