Indeed. It doesn't look that hard: AFAICS the problem is just that
process_sql_command() is making premature decisions about whether to
extract parameters from the SQL commands. Proposed patch attached.
Great. Patch looks good to me.
Too me as well: code looks ok, patch applies, compiles,
>> Not really objecting, but an even better fix might be to remove the
>> restriction on the order in which the options can be specified.
>
> Indeed. It doesn't look that hard: AFAICS the problem is just that
> process_sql_command() is making premature decisions about whether to
> extract paramet
> Not really objecting, but an even better fix might be to remove the
> restriction on the order in which the options can be specified.
+100 :-)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-ha
Robert Haas writes:
> On Tue, Aug 1, 2017 at 10:03 PM, Tatsuo Ishii wrote:
>> I found an error message in pgbench is quite confusing.
> Not really objecting, but an even better fix might be to remove the
> restriction on the order in which the options can be specified.
Indeed. It doesn't look
Hello Tatsuo-san,
I found an error message in pgbench is quite confusing.
pgbench -S -M extended -c 1 -T 30 test
query mode (-M) should be specified before any transaction scripts (-f or -b)
Since there's no -f or -b option is specified, users will be
confused.
Indeed.
Actually the error o
On Tue, Aug 1, 2017 at 10:03 PM, Tatsuo Ishii wrote:
> I found an error message in pgbench is quite confusing.
>
> pgbench -S -M extended -c 1 -T 30 test
> query mode (-M) should be specified before any transaction scripts (-f or -b)
>
> Since there's no -f or -b option is specified, users will be
I found an error message in pgbench is quite confusing.
pgbench -S -M extended -c 1 -T 30 test
query mode (-M) should be specified before any transaction scripts (-f or -b)
Since there's no -f or -b option is specified, users will be
confused. Actually the error occurs because pgbench implicitly
On 08/10/2013 02:43 AM, Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> More seriously, with interpolated strings for relation names etc
>> it can be hard to know which chunks to search for, and search
>> engines aren't always good at having the whole message thrown at
>> th
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> More seriously, with interpolated strings for relation names etc it can
> be hard to know which chunks to search for, and search engines aren't
> always good at having the whole message thrown at them.
It's not perfect, but if the searches are gettin
I seem to remember somebody proposed an errurl() macro so that we could
add URLs to certain particularly confusing error reports.
[searches the archives] Bah, that was me, and some other ideas were
proposed:
http://www.postgresql.org/message-id/48ca9d5f.6060...@esilo.com
--
Álvaro Herrera
On 08/10/2013 12:09 AM, Stephen Frost wrote:
> Perhaps we should add an area to our documentation which provides
> more information about the specific error messages which PostgreSQL
> returns? That's not a terribly exciting bit of documentation to
> write, but perhaps it would be very useful for o
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This is all sufficiently bizarre that I don't know if there's an
> easy explanation.
It occurs to me that users, when faced with complex error messages, are
very likely to go to their favorite search engine with it and rarely
does that lead them to any docu
Peter Eisentraut writes:
> I'm having trouble parsing this:
> ERROR: aggregate functions are not allowed in FROM clause of their own query
> level
> The example in the regression tests is:
> -- LATERAL can be used to put an aggregate into the FROM clause of its query
> select 1 from tenk1 a, l
I'm having trouble parsing this:
ERROR: aggregate functions are not allowed in FROM clause of their own query
level
The example in the regression tests is:
-- LATERAL can be used to put an aggregate into the FROM clause of its query
select 1 from tenk1 a, lateral (select max(a.unique1) from in
14 matches
Mail list logo
