-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Jun 04, 2010 at 06:15:09PM -0400, Farid Zidan wrote:
[...]
> Let me reiterate the example, maybe it was too terse and you did not
> read it carefully,
No. I think most readers here have understood your problem perfectly.
Don't underestimate t
On Fri, Jun 4, 2010 at 11:15 PM, Farid Zidan wrote:
> Now this not rocket science, it's simple insert statement where we do not
> want duplicates inserted. Works on 10 other DBMSs.
>
I find usually when one person is arguing something is complex and
someone else is arguing it's simple it's the pe
On Fri, 4 Jun 2010, Farid Zidan wrote:
Here is actual statements I am running and like I said they work for all 9+
DBMSs (I use ODBC and{fn user()} is the ODBC cross-dbms syntax for the
current user ID):
'2010-04-30 00:00:00',
'2010-04-30 00:00:00',
{fn user() }
If you're into using standa
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
Title: Signature
Hello Greg,
I suspect what they're doing is doing a DISTINCT of the text values
and then converting the results. That's not the same as what you're
suggesting it do (insert distinct timestamp values) since different
text values can represent the same timestamp. For example
On Fri, Jun 4, 2010 at 5:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> Is there really a use case for users fiddling with pg_proc, pg_class,
>> etc. directly?
>
> There's a use case for *superusers* to fiddle with them, yes.
> (Superusers are presumed to be adults.) I think I recommend a quic
>Farid Zidan wrote:
> 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
Not really. In versions prior to 8.3 it did automagically convert
like that. PostgreSQL has some pretty fancy features involving
Excerpts from Kevin Grittner's message of vie jun 04 14:53:17 -0400 2010:
> Same here. I suspect that this is much more commonn than many
> PostgreSQL developers realize; and I think it makes a reasonable
> case for at least an *option* to quote all identifiers emitted by
> pg_dump.
I don't thin
Robert Haas writes:
> Is there really a use case for users fiddling with pg_proc, pg_class,
> etc. directly?
There's a use case for *superusers* to fiddle with them, yes.
(Superusers are presumed to be adults.) I think I recommend a quick
UPDATE on some catalog at least once a month on the list
On Fri, Jun 4, 2010 at 4:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Personally, I think it would be better to put some work into making
>> allow_system_table_mods a little less simple-minded. Right now,
>> !allow_system_table_mods prohibits you from doing perfectly sensible
>> things (as in
Bernd Helmle writes:
> Out of curiosity, why is this a "bug" now?
It isn't...
> And wouldn't introducing backpatching such behavorial changes to pg_dump
> violate our policy in *not* to change such things in minor releases?
That was just an off-the-cuff idea, it has certainly not become policy
--On 4. Juni 2010 15:19:42 -0400 Bruce Momjian wrote:
That would make the bug go away,
rather than require users to use a special flag (and find out only after
they were doing the reload).
Out of curiosity, why is this a "bug" now? We recommend migration
procedures always to use the pg_dum
Robert Haas writes:
> Personally, I think it would be better to put some work into making
> allow_system_table_mods a little less simple-minded. Right now,
> !allow_system_table_mods prohibits you from doing perfectly sensible
> things (as in the OP's original example) yet still allows you to do
On Thu, Jun 3, 2010 at 1:21 PM, Tom Lane wrote:
> Gurjeet Singh writes:
>> allow_system_table_mods needs a restart :( .Yet another parameter I wish was
>> changeable on the fly.
>
> I'm not sure there's any compelling reason why it couldn't be SUSET.
> Maybe a TODO ...
Personally, I think it wou
On Fri, Jun 4, 2010 at 7:18 PM, Farid Zidan wrote:
> If a simple SQL statement works on 9+ different databases
For what it's worth are you sure it works as you expect in these other
databases?
I suspect what they're doing is doing a DISTINCT of the text values
and then converting the results. Th
David Fetter wrote:
> On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
> > Kevin Grittner wrote:
> > > Hartmut Goebel wrote:
> > >
> > > > The application already quotes all column names :-) It's using a
> > > > generic framework which does not (and must not) rely on column
> > > >
David Fetter wrote:
> It seems like something that's doable by pg_dump as a "default
> off" option. TODO for 9.1?
Sounds good to me.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
> Kevin Grittner wrote:
> > Hartmut Goebel wrote:
> >
> > > The application already quotes all column names :-) It's using a
> > > generic framework which does not (and must not) rely on column
> > > names being non-keywords.
> >
>
Kevin Grittner wrote:
> Hartmut Goebel wrote:
>
> > The application already quotes all column names :-) It's using a
> > generic framework which does not (and must not) rely on column
> > names being non-keywords.
>
> Same here. I suspect that this is much more commonn than many
> PostgreSQL
Hartmut Goebel wrote:
> The application already quotes all column names :-) It's using a
> generic framework which does not (and must not) rely on column
> names being non-keywords.
Same here. I suspect that this is much more commonn than many
PostgreSQL developers realize; and I think it mak
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
Am 04.06.2010 14:57, schrieb Stephen Frost:
> * Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
>> Am 04.06.2010 13:56, schrieb Stephen Frost:
>>> Quoting all column names makes the dump script much more difficult for
>>> human consumption, which is important.
>>
>> I don't agree with you here.
>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
Am 04.06.2010 13:56, schrieb Stephen Frost:
> Quoting all column names makes the dump script much more difficult for
> human consumption, which is important.
I don't agree with you here. But this may be a matter of personal taste.
Esp. I think, functionality is much ore important than a small de
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
> Am 04.06.2010 13:56, schrieb Stephen Frost:
> > Quoting all column names makes the dump script much more difficult for
> > human consumption, which is important.
>
> I don't agree with you here. But this may be a matter of personal taste.
>
>
> As I saw, ecpg preprocessor is unable to handle "SELECT ... RETURNING INTO
> ... " queries due to the following line in
I take it you mean INSERT/DELETE/UPDATE and not SELECT right? And yes, those
results weren't moved into C space. I more or less applied your patch to 8.3,
8.4 and 9.0, so the n
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
> Am 03.06.2010 16:15, schrieb Tom Lane:
> > That was considered and rejected long ago. Readability of the dump
> > script is something that we put a nonzero value on.
>
> I assume you mean readability for humans?!
Yes, readability for humans
Am 03.06.2010 20:07, schrieb Tom Lane:
> "Kevin Grittner" writes:
>> Hartmut Goebel wrote:
>>> If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
>>> starting (something like "Database version mismatch").
>
>> You need to be running the old server using 8.3 software and while
>>
Am 03.06.2010 16:15, schrieb Tom Lane:
>> Solution: pg_dump should quote *all* column-names, no matter if they are
>> keywords or not.
>
> That was considered and rejected long ago. Readability of the dump
> script is something that we put a nonzero value on.
Sorry, I do not understand this.
I
35 matches
Mail list logo
