From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] Count(*) throws error |
Date: | 2007-07-12 14:40:46 |
Message-ID: | 17867.1184251246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote:
>> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
>>> Seems like we could be slightly more friendly without too much bother:
>>> at least only substitute after the VALUES clause in INSERT.
>>
>> Surely you jest.
> No. There are a places where parameters clearly aren't allowed, so
> making the substitutions in those places can easily be prevented. The
> remainder of the problem is as hard as you think, but getting half way
> there seems very easy.
It's not nearly as easy as you think. Even for the limited case of
the column list for an INSERT, consider
DECLARE i int; j int;
...
INSERT INTO mytable (arraycol[i]) VALUES (j);
Considering that the current plpgsql parser doesn't have any knowledge
*at all* of the syntactic structure of individual SQL commands, even
teaching it to recognize an INSERT column list correctly would be a huge
addition of code. The payback for that seems darn small considering
that (1) that's only a small portion of the trouble cases and (2) it is
very easy for users to recognize a failure in this context, whereas many
of the other trouble cases aren't mechanically recognizable at all.
Ultimately we have to do a better job of teaching users to recognize
this issue for themselves; which is why I think it's basically a
documentation problem.
The other problem with trying to inject a small amount of smarts is that
it complicates explaining the system. I think the docs have to explain
*exactly* how the substitution works (which they fail to do right now,
but I intend to make 'em do so today), and putting in any special cases
will make that explanation longer and more confusing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Koen Vermeer | 2007-07-12 14:44:36 | Re: Force SSL / username combination |
Previous Message | Csaba Nagy | 2007-07-12 14:31:23 | Re: Database corruption: finding the bad block |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-07-12 14:52:02 | Re: xlog switch & last record before the switch |
Previous Message | Florian G. Pflug | 2007-07-12 14:17:59 | xlog switch & last record before the switch |