Ошибка субд 42601

Syntax errors are quite common while coding.

But, things go for a toss when it results in website errors.

PostgreSQL error 42601 also occurs due to syntax errors in the database queries.

At Bobcares, we often get requests from PostgreSQL users to fix errors as part of our Server Management Services.

Today, let’s check PostgreSQL error in detail and see how our Support Engineers fix it for the customers.

What causes error 42601 in PostgreSQL?

PostgreSQL is an advanced database engine. It is popular for its extensive features and ability to handle complex database situations.

Applications like Instagram, Facebook, Apple, etc rely on the PostgreSQL database.

But what causes error 42601?

PostgreSQL error codes consist of five characters. The first two characters denote the class of errors. And the remaining three characters indicate a specific condition within that class.

Here, 42 in 42601 represent the class “Syntax Error or Access Rule Violation“.

In short, this error mainly occurs due to the syntax errors in the queries executed. A typical error shows up as:

Here, the syntax error has occurred in position 119 near the value “parents” in the query.

How we fix the error?

Now let’s see how our PostgreSQL engineers resolve this error efficiently.

Recently, one of our customers contacted us with this error. He tried to execute the following code,

CREATE OR REPLACE FUNCTION prc_tst_bulk(sql text)
RETURNS TABLE (name text, rowcount integer) AS
$$
BEGIN
WITH m_ty_person AS (return query execute sql)
select name, count(*) from m_ty_person where name like '%a%' group by name
union
select name, count(*) from m_ty_person where gender = 1 group by name;
END
$$ LANGUAGE plpgsql;

But, this ended up in PostgreSQL error 42601. And he got the following error message,

ERROR: syntax error at or near "return"
LINE 5: WITH m_ty_person AS (return query execute sql)

Our PostgreSQL Engineers checked the issue and found out the syntax error. The statement in Line 5 was a mix of plain and dynamic SQL. In general, the PostgreSQL query should be either fully dynamic or plain. Therefore, we changed the code as,

RETURN QUERY EXECUTE '
WITH m_ty_person AS (' || sql || $x$)
SELECT name, count(*)::int FROM m_ty_person WHERE name LIKE '%a%' GROUP BY name
UNION
SELECT name, count(*)::int FROM m_ty_person WHERE gender = 1 GROUP BY name$x$;

This resolved the error 42601, and the code worked fine.

[Need more assistance to solve PostgreSQL error 42601?- We’ll help you.]

Conclusion

In short, PostgreSQL error 42601 occurs due to the syntax errors in the code. Today, in this write-up, we have discussed how our Support Engineers fixed this error for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Your function would work like this:

CREATE OR REPLACE FUNCTION prc_tst_bulk(sql text)
  RETURNS TABLE (name text, rowcount int)
  LANGUAGE plpgsql AS 
$func$
BEGIN
   RETURN QUERY EXECUTE '
   WITH v_tb_person AS (' || sql || $x$)
   SELECT name, count(*)::int FROM v_tb_person WHERE nome LIKE '%a%' GROUP BY name
   UNION
   SELECT name, count(*)::int FROM v_tb_person WHERE gender = 1 GROUP BY name$x$;
END     
$func$;

Call:

SELECT * FROM prc_tst_bulk($$SELECT a AS name, b AS nome, c AS gender FROM tbl$$)

You cannot mix plain and dynamic SQL the way you tried to do it. The whole statement is either all dynamic or all plain SQL. So I am building one dynamic statement to make this work. You may be interested in the chapter about executing dynamic commands in the manual.

The aggregate function count() returns bigint, but you had rowcount defined as integer, so you need an explicit cast ::int to make this work.

I use dollar quoting to avoid quoting hell.

However, is this supposed to be a honeypot for SQL injection attacks or are you seriously going to use it? For your very private and secure use, it might be ok-ish — though I wouldn’t even trust myself with a function like that. If there is any possible access for untrusted users, such a function is a loaded footgun. It’s impossible to make this secure.

Craig (a sworn enemy of SQL injection) might get a light stroke when he sees what you forged from his answer to your preceding question.

The query itself seems rather odd, btw. The two SELECT terms might be merged into one. But that’s beside the point here.

   Лекс

07.02.17 — 17:24

   Artful Den

1 — 07.02.17 — 17:31

Выгрузку базы под 8.2, загрузку под 8.3 пробовали?

   Лекс

2 — 07.02.17 — 17:36

Нет. Базы на постгре висят уже, обновилась только платформа сервера.

   Artful Den

3 — 07.02.17 — 17:38

(2) Так вроде бы ничего не мешает попробовать, поднимите 2 сервера 1с параллельно, если 8.2 не осталось уже.

   Фрэнки

4 — 07.02.17 — 17:54

с какого на какой релиз 1С был переход?

   Фрэнки

5 — 07.02.17 — 17:54

то, что прыгнули на самый последний — это конечно здорово, но с какого спрыгивал — не написал

   Karamzin

6 — 07.02.17 — 18:04

Не исправили видимо. Мы переходили на 8.3.9.2033 — та же фигня была. Пришлось поставить 8.3.8.1747 — минимально нужный для Бухгалтерии 2.0. Все нормально завелось.

   pessimist

7 — 07.02.17 — 18:11

(0) 8.3.9.2170 не поддерживает работу с PostgreSQL 9.0.3-3.1C(x64), если вы используете сборку 1С. В документации это отражено. И наоборот, старые платформы 1С не поддерживают новые сборки PostgreSQL.

Теоретически вероятно можно собрать версию 9.0.3 для работы с платформой  8.3.9. Практически в этом нет смысла.

Выгрузка в dt на старой платформе и загрузка из dt на новой платформе с новым SQL сервером.

Несколько SQL серверов могут жить под одной ОС. Например по портам разнести. Или по интерфейсам.

   Karamzin

8 — 07.02.17 — 18:14

(7) У нас стоит 9.4.2-1.1C, и это нам не помогло.

   Karamzin

9 — 07.02.17 — 18:15

Последняя 1с-кая сборка от 17.06.15. Тогда 8.3.9, наверное, только в мыслях у разработчика была.

   ansh15

10 — 07.02.17 — 18:23

   Karamzin

11 — 07.02.17 — 18:44

(10) Видели. Пока решили не пробовать. Но спасибо за ссылку!

   Лекс

12 — 08.02.17 — 12:59

   Лекс

13 — 08.02.17 — 13:52

(7)  если не секрет, ссыль можете дать, где в документации указано, что не работает, что-то не нашел

   dmrjan

14 — 08.02.17 — 14:16

Вот тут вроде как подобная тема обсуждается:

http://postgresql.ru.net/node/214401

«В одном из ответов говориться, что до версии 9.1 операторы DELETE, UPDATE, INSERT не могут быть использованы в подзапросах.»

   dmrjan

15 — 08.02.17 — 14:23

(10) Все-таки лучше начинать с 9.6.1, там патчи для 1С доработанные. Все равно разработчики говорят, что «экспериментальная» практически такая же боевая.

   pessimist

16 — 08.02.17 — 16:49

(15) Да, нормально работает, потестировал на ней наши базы, проблем не возникало.

Добрый вечер. Есть выражение:

$this->insertStmt = $this->connection->getPdo()->prepare("
    INSERT INTO files (
           real_name, 
           virtual_name, 
           album,
           size,
           resolution, 
           duration, 
           comment,
           path,
           user
    ) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
");

Которое вызывается как обычно:

protected function doInsert(object $object)
{
    $values = [
        $object->getRealName(),
        $object->getVirtualName(),
        $object->getAlbum(),
        $object->getSize(),
        $object->getResolution(),
        $object->getDuration(),
        $object->getComment(),
        $object->getPath(),
        $object->getUser(),
    ];
       
    $this->insertStmt->execute($values);
}

Примерное содержание $values:

array(9) { 
    [0]=> string(15) "BvrK9z6UPxY.jpg" 
    [1]=> string(16) "1265dde1c67abc1c" 
    [2]=> string(23) "По умолчанию" 
    [3]=> int(54973) 
    [4]=> string(7) "720x430" 
    [5]=> NULL 
    [6]=> string(0) "" 
    [7]=> string(108) "files/id5cd487313a93a/По умолчанию/2019-05-10/1265dde1c67abc1c.jpg" 
    [8]=> string(15) "id5cd487313a93a" 
}

Сообщение ошибки:

Type: PDOException
Code: 42601
Message: SQLSTATE[42601]: Syntax error: 7 ОШИБКА: ошибка синтаксиса (примерное положение: "user") LINE 11: user ^

С точки зрения синтаксиса вроде все верно, много раз перепроверил, IDE ни на что не ругается. В чем трабл, господа?