Ошибка тип bigserial не существует

As explained in the documentation, SERIAL is not a datatype, but a shortcut for a collection of other commands.

So while you can’t change it simply by altering the type, you can achieve the same effect by running these other commands yourself:

CREATE SEQUENCE temp_id_seq;
ALTER TABLE temp ALTER COLUMN id SET NOT NULL;
ALTER TABLE temp ALTER COLUMN id SET DEFAULT nextval('temp_id_seq');
ALTER SEQUENCE temp_id_seq OWNED BY temp.id;

Altering the owner will ensure that the sequence is removed if the table/column is dropped. It will also give you the expected behaviour in the pg_get_serial_sequence() function.

Sticking to the tablename_columnname_seq naming convention is necessary to convince some tools like pgAdmin to report this column type as BIGSERIAL. Note that psql and pg_dump will always show the underlying definition, even if the column was initially declared as a SERIAL type.

As of Postgres 10, you also have the option of using an SQL standard identity column, which handles all of this invisibly, and which you can easily add to an existing table:

ALTER TABLE temp ALTER COLUMN id
  ADD GENERATED BY DEFAULT AS IDENTITY

GORM Playground Link

go-gorm/playground#391

Existing database without using GORM :

DROP TABLE IF EXISTS "events";
DROP SEQUENCE IF EXISTS events_id_seq;
CREATE SEQUENCE events_id_seq INCREMENT 1 MINVALUE 1 MAXVALUE 2147483647 CACHE 1;
CREATE TABLE "public"."events" (
    "id" integer DEFAULT nextval('events_id_seq') NOT NULL,
    "town" text NOT NULL,
    "latitude" real NOT NULL,
    "longitude" real NOT NULL,
    "kind" text NOT NULL,
    "species" text NOT NULL,
    "description" text NOT NULL,
    "user_publisher" integer NOT NULL,
    "time" timestamp NOT NULL,
    "disabled" integer NOT NULL,
    "report" integer NOT NULL,
    CONSTRAINT "events_pkey" PRIMARY KEY ("id")
) WITH (oids = false);

Model used with GORM :

type Event struct {
	gorm.Model
	Town           string    `gorm:"not null"`
	Latitude       float64   `gorm:"not null"`
	Longitude      float64   `gorm:"not null"`
	Kind           string    `gorm:"not null"`
	Species        string    `gorm:"not null"`
	Description    string    `gorm:"not null"`
	User_Publisher int       `gorm:"not null"`
	Time           time.Time `gorm:"not null"`
	Disabled       int       `gorm:"not null"`
	Report         int       `gorm:"not null"`
}

Function that opens the database and migrates the data :

func (store PostgresRepository) Open(dsn string) (*PostgresRepository, error) {
	// Open database
	db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
	if err != nil {
		return nil, err
	}
	log.Info().Msg("Connected to db")

	// Create the new SQLite repository
	sql := NewPostgresRepository(db)

	// Migration database
	if err := db.AutoMigrate(&Event{}); err != nil {
		return nil, err
	}

	return sql, nil
}

Error : 2021/10/19 15:14:19 /home/enzo/go/pkg/mod/gorm.io/driver/postgres@v1.1.2/migrator.go:252 ERROR: type «bigserial» does not exist (SQLSTATE 42704)

Description

Before using GORM I was using pgxscan and doing automatic migrations via a script.
Recently I switched to GORM which is more efficient but I get this error during the migration.

Why do I get this error?

Same problem here #4765

Невозможно изменить тип данных bigint на smallserial в существующей базе данных [duplicate]

Мы оказываемся во вселенной, которая, по-видимому, развивается по измерению, которое мы называем «временем». Мы не понимаем, какое время, но мы разработали абстракции и словарный запас, которые позволяют рассуждать и говорить об этом: «прошлое», «настоящее», «будущее», «до», «после».

Компьютерные системы, которые мы строим — все больше и больше — имеют время как важное измерение. В будущем будут созданы определенные вещи. Тогда другие вещи должны произойти после того, как эти первые вещи в конечном итоге произойдут. Это основное понятие, называемое «асинхронность». В нашем мире с более сложной сетью наиболее распространенный случай асинхронности ожидает, что какая-то удаленная система ответит на какой-либо запрос.

Рассмотрим пример. Вы называете молочника и заказываете молоко. Когда это произойдет, вы хотите положить его в свой кофе. Вы не можете положить молоко в свой кофе прямо сейчас, потому что его еще нет. Вы должны подождать, пока это произойдет, прежде чем положить его в свой кофе. Другими словами, следующее не будет работать:

Поскольку JS не знает, что ему нужно дождаться окончания order_milk , прежде чем он выполнит put_in_coffee . Другими словами, он не знает, что order_milk является асинхронным — это то, что не приведет к молоку до некоторого будущего времени. JS и другие декларативные языки, выполняйте один оператор за другим, не ожидая.

Классический подход JS к этой проблеме, используя тот факт, что JS поддерживает функции как объекты первого класса, которые могут быть переданы, заключается в передаче функции в качестве параметра для асинхронного запроса, который затем будет вызываться, когда он будет выполнять свою задачу в будущем. Это подход «обратного вызова». Это выглядит так:

order_milk запускает, заказывает молоко, тогда, когда и только когда он прибывает, он вызывает put_in_coffee .

Проблема с этот подход обратного вызова состоит в том, что он загрязняет нормальную семантику функции, сообщающей свой результат с помощью return ; вместо этого функции должны сообщать свои результаты, вызывая обратный вызов, заданный как параметр. Кроме того, этот подход может быстро стать громоздким при работе с более длинными последовательностями событий. Например, предположим, что я хочу дождаться, когда молоко будет помещено в кофе, а затем и только затем выполните третий шаг, а именно — выпить кофе. В конце концов мне нужно написать что-то вроде этого:

, где я перехожу к put_in_coffee как к молоку, чтобы положить в него, так и к действию ( drink_coffee ), чтобы выполнить как только молоко был введен. Такой код становится трудно писать, читать и отлаживать.

В этом случае мы могли бы переписать код в вопросе как:

Enter обещает

. Это была мотивация для понятия «обещание», которое является особым типом ценности, представляющим собой будущий или асинхронный результат какого-то рода. Он может представлять что-то, что уже произошло, или это произойдет в будущем, или, возможно, никогда не произойдет вообще. Обещания имеют один метод, названный then , которому вы передаете действие, которое должно быть выполнено, когда был достигнут результат, представленный обещанием.

В случае нашего молока и кофе мы создаем order_milk , чтобы вернуть обещание о прибытии молока, затем укажите put_in_coffee как действие then следующим образом:

. Одно из преимуществ этого заключается в том, что мы можем объединить их вместе для создания последовательностей будущие вхождения («цепочка»):

Давайте применим обещания к вашей конкретной проблеме. Мы завершим нашу логику запроса внутри функции, которая возвращает обещание:

На самом деле, все, что мы сделали, добавлено к return к вызову $.ajax . Это работает, потому что jQuery $.ajax уже возвращает вид обетоподобной вещи. (На практике, не вдаваясь в подробности, мы предпочли бы обернуть этот вызов, чтобы вернуть реальное обещание, или использовать некоторую альтернативу $.ajax , которая делает это.) Теперь, если мы хотим загрузить файл и дождаться его завершите, а затем сделайте что-нибудь, мы можем просто сказать

. При использовании обещаний мы заканчиваем передачу множества функций в then , поэтому часто полезно использовать более компактные функции стрелок в стиле ES6:

Ключевое слово async

Но все еще есть что-то неопределенное в том, что нужно писать код одним способом, если синхронно и совершенно по-другому, если асинхронно. Для синхронного мы пишем

, но если a является асинхронным, с обещаниями мы должны написать

Выше, мы сказали: «JS не имеет никакого способа узнать что ему нужно дождаться завершения первого вызова, прежде чем он выполнит второй ». Было бы неплохо, если бы можно было сказать JS? Оказывается, существует ключевое слово await , используемое внутри специального типа функции, называемого функцией «async». Эта функция является частью предстоящей версии ES, но уже доступна в транспилерах, таких как Babel, с учетом правильных настроек. Это позволяет нам просто написать

. В вашем случае вы могли бы написать что-то вроде

Источник

ERROR Database error 42704: type «number» does not exist while migrating from sqlite #1284

Getting ERROR Database error 42704: type «number» does not exist while migrating from sqlite

2021-05-09T18:10:20.272691+01:00 ERROR Database error 42704: type «number» does not exist QUERY: CREATE TABLE builds ( build_id bigserial, build_repo_id bigint, build_trigger text, build_number bigint, build_parent bigint, build_status text, build_error text, build_event text, build_action text, build_link text, build_timestamp bigint, build_title text, build_message text, build_before text, build_after text, build_ref text, build_source_repo text, build_source text, build_target text, build_author text, build_author_name text, build_author_email text, build_author_avatar text, build_sender text, build_deploy text, build_params text, build_started bigint, build_finished bigint, build_created bigint, build_updated bigint, build_version bigint, build_debug boolean default ‘0’, build_cron text default », build_deploy_id number default ‘0’ ); 2021-05-09T18:10:20.290184+01:00 FATAL Failed to create the schema, see above. Initially the error was the octet sequence #(128) cannot be decoded. An unhandled error condition has been signalled: :UTF-8 stream decoding error on # : the octet sequence #(128) cannot be decoded. «>

• data that is being loaded, if relevant

• How the data is different from what you expected, if relevant
• It seems like as the build_deploy_id is type of number and this type is not present in PostgreSQL, So I have to create a new table with type bigint and than copied the data after renaming the table to get this working, so just checking if this can be handled

The text was updated successfully, but these errors were encountered:

Источник

Error 42704 — does mean what?

[Cross post from -SQL]

I am trying to model a macro system where I have simple things, and more complex thing consisting of simple things. To do that I have
«invented» this table definition:

CREATE TABLE params
(
param_id serial NOT NULL,
name text NOT NULL,
unit text,
real_param_id integer[],
CONSTRAINT params_pkey PRIMARY KEY (param_id),
CONSTRAINT params_name_key UNIQUE (name)
);

with a complex and 2 simple things:
INSERT INTO params VALUES (1, ‘a’, NULL, ‘<1,2>‘);
INSERT INTO params VALUES (2, ‘a1’, ‘1’, NULL);
INSERT INTO params VALUES (3, ‘a2’, ‘2’, NULL);

with this SQL:
select name, array[array[name::text,unit::text]]::text[][]
from params
where real_param_id is null
union
select name, array(select cast(‘<«‘||a.name||’»,»‘||a.unit||’»>‘ as text[])
from params a,
(select c.param_id, unnest(real_param_id)
from params c
where c.param_id=b.param_id) as j
where a.param_id = j.unnest)
from params b
where b.real_param_id is not null
order by name

But I am getting this error which I do not find very informative, as I know i can have arrays of text and arrays of those, so what is up?

ERROR: could not find array type for data type text[]
SQL state: 42704

Suggestions as to what to do to circumvent this error, and also to maybe more elegant ways to solve the fundamental problem will be received
with pleasure.

This is tested on both PostgreSQL 9.2.1 and a 9.1.*

Источник

getting SQL state: 42704 error creating foreign table #240

Hi Laurenz, I’m running postgresql under ubuntu and i’m trying migration with oracle_fdw but I stopped facing an issue creating a foreign table. Could You help me?
I compiled oracle_fwd 1.5 (2.0 was giving me dependencies issues) and succesfully installed extension on my ubuntu.
Following instructions I create the foreign server:
CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver ‘//10.10.20.100:1521/GDBT’);
I granted user postgres:
GRANT USAGE ON FOREIGN SERVER oradb TO postgres;
then I created user mapping:
CREATE USER MAPPING FOR postgres SERVER oradb OPTIONS (user ‘UTENTE’, password ‘pwd’);
now I’m trying to create a foreing table:

but i’m getting the following error:

What am I doing wrong?

note1: I can retrieve foreign server by;
SELECT srvname,srvoptions FROM pg_foreign_server;
getting:
oradb
and foreign connection detail:
SELECT oracle_diag(‘oradb’)
getting:
oracle_fdw 1.5.0, PostgreSQL 9.3.4, Oracle client 12.2.0.1.0, Oracle server 11.2.0.4.0

note2: I can succefully connect to oracle by sqlplus:
sqlplus UTENTE/pwd@//10.10.20.100:1521/GDBT
having access to TEST table:

note3: I’m currently using other foreign tables with postgres_fdw extension

The text was updated successfully, but these errors were encountered:

Источник

Преобразование типа столбца PostgreSQL из bigint в bigserial

Когда я пытаюсь изменить тип данных столбца в таблице с помощью команды alter.

Как изменить тип данных с bigint на bigserial?

4 ответа

Это простой обходной путь:

Похоже, в этом вопросе много профессионалов. если в исходной таблице действительно были данные, то реальный ответ на эту дилемму заключается в том, чтобы в первую очередь правильно спроектировать базу данных. Однако в этом случае для изменения правила столбца (типа) потребуется проверка целостности этого столбца для новой парадигмы. И, не забывайте, везде, где этот столбец манипулируется (добавляется/обновляется), это нужно будет изучить.

Если это новая таблица, то все в порядке, просто: удалите столбец и повторно добавьте новый столбец (за вас позаботится о последовательности). Опять же, дизайн, дизайн, дизайн.

Я думаю, что мы все запутались в этом.

ALTER изменение столбца с BIGINTEGER на BIGSERIAL для автоматического увеличения не будет работать. BIGSERIAL не является истинным типом, это трюк, который автоматизирует создание PK и SEQUENCE .

Вместо этого вы можете создать последовательность самостоятельно, а затем назначить ее по умолчанию для столбца:

Как поясняется в документации, SERIAL — это не тип данных, а ярлык для набора других команд.

Поэтому, хотя вы не можете изменить его, просто изменив тип, вы можете добиться того же эффекта, выполнив эти другие команды самостоятельно:

Изменение владельца гарантирует, что последовательность будет удалена, если таблица/столбец будет удалена. Это также даст вам ожидаемое поведение в pg_get_serial_sequence().

Придерживаться соглашения об именах tablename_columnname_seq необходимо, чтобы некоторые инструменты, такие как pgAdmin, сообщали об этом типе столбца как BIGSERIAL . Обратите внимание, что psql и pg_dump всегда будут отображать базовое определение, даже если столбец изначально был объявлен как тип SERIAL .

Источник

Как объяснено в документации, SERIAL это не тип данных, а ярлык для набора других команд.

Поэтому, хотя вы не можете изменить его, просто изменив тип, вы можете добиться того же эффекта, выполнив эти другие команды самостоятельно:

CREATE SEQUENCE temp_id_seq;
ALTER TABLE temp ALTER COLUMN id SET NOT NULL;
ALTER TABLE temp ALTER COLUMN id SET DEFAULT nextval('temp_id_seq');
ALTER SEQUENCE temp_id_seq OWNED BY temp.id;

Изменение владельца обеспечит удаление последовательности, если таблица / столбец будет удалена. Это также даст вам ожидаемое поведение в функции pg_get_serial_sequence().

Придерживаться tablename_columnname_seq Соглашение об именовании необходимо, чтобы некоторые инструменты, такие как pgAdmin, сообщали об этом типе столбца как BIGSERIAL, Обратите внимание, что psql и pg_dump всегда будут показывать базовое определение, даже если столбец был первоначально объявлен как SERIAL тип.

Начиная с Postgres 10, у вас также есть возможность использовать стандартный столбец идентификаторов SQL, который обрабатывает все это незаметно и который можно легко добавить в существующую таблицу:

ALTER TABLE temp ALTER COLUMN id
  ADD GENERATED BY DEFAULT AS IDENTITY