On Wed, 12 Feb 2025, Adrian Klaver wrote:
The point Tom was making is that psql uses readline for it's editing
positioning and that for him Emacs movement commands work in psql.
Adrian,
Thanks for clarifying; the emacs commands work for me, too, in psql.
Regards,
Rich
On Wed, 12 Feb 2025, Tom Lane wrote:
On my machine, Ctrl-Left/Right don't seem to do anything, but the usual
Emacs combinations Ctrl-A, Ctrl-E, Escape-B, Escape-F and so on work in
psql. I don't believe I did anything special to configure that. Check your
local readline documentation.
Tom,
I
My web searches suggest that using the psql command line I'm limited to
moving the cursor one character at a time. Is there a way to use a small
editor, e.g., joe on linux, to move by words or to the begining and end of
the line?
TIA,
Rich
On Tue, 4 Feb 2025, Rich Shepard wrote:
I'll make new tables today.
That did not work as well as I expected. Instead, I added a new column (type
`serial') to each of the two lookup tables. That adds a PK to each while
retaining the table and column names referenced by other table
On Tue, 4 Feb 2025, David G. Johnston wrote:
Is the use of FK here intentional or a typo?
Sigh, typo. Should be PK.
Rich
On Tue, 4 Feb 2025, Rob Sargent wrote:
Unless your lookup tables are huge I would create a new table matching
your current table but with an identity column and load from you original
table.
I created a new table:
create table ind_types_lu (
ind_nbr serial primary key,
ind_name varchar(32
On Tue, 4 Feb 2025, David G. Johnston wrote:
It’s the FK side where the cost savings are experienced.
David,
Okay.
Thanks,
Rich
On Tue, 4 Feb 2025, Ron Johnson wrote:
Does your lookup table just have one column? (That's what your question
seems to imply, but that makes no sense, since the whole point of a lookup
table is to store some sort of a code in the "child" table instead of the
whole text of the description.)
R
On Tue, 4 Feb 2025, David G. Johnston wrote:
The point of a lookup table is to provide a unique list of authoritative
values for some purpose. Kinda like an enum. But having the label serve as
the unique value is reasonable - we only add surrogates for optimization.
David,
The industrytypes t
On Tue, 4 Feb 2025, David G. Johnston wrote:
Most do (have a surrogate PK) since it removes cascading updates and is a
smaller value.
Lots of alter tables and update queries.
David,
That's a good point.
Thanks,
Rich
On Tue, 4 Feb 2025, Rob Sargent wrote:
I would definitely add an Id for each of the looked up values. The code
can use the Id (for the join or lookup) and the string value can safely be
changed (think typo) without ripple effect. It also prevents other tables
from referencing the lookup witrh b
Should lookup tables have a numeric FK column as well as the description column?
If so, how should I add an FK to the two lookup tables in my database?
TIA,
Rich
On Thu, 30 Jan 2025, Rich Shepard wrote:
Thanks again, David. I didn't know that's the section I need.
David/Ron, et al.:
Got it (example on page 2126 of the doc):
-- Display person_nbr, lname, fname, direct_phone, email from people, contact
history from contacts.
-- prompt for
On Thu, 30 Jan 2025, David G. Johnston wrote:
That is what \prompt is for. You have the correct meta-command, you were
capturing user input just fine. Read about how to use variables in
queries for the part you are missing.
Specifically the section of the psql docs titled:
SQL Interpolation
On Thu, 30 Jan 2025, Rich Shepard wrote:
Thank you. I'll look into using the \set command.
My web searches find many examples of using the \set command, but none
getting user input with \prompt.
Please point me to a reference where I can learn how to get the user input
string into the s
On Thu, 30 Jan 2025, David G. Johnston wrote:
Prompt isn’t your issue. Prompt stores the value into a variable. Read how
to reference variables in a psql script.
David,
Thank you. I'll look into using the \set command.
Rich
I want to use the \prompt command to get user input for a query. My script
fails:
-- Display person_nbr, lname, fname, direct_phone, email from people, contact
history from contacts.
-- prompt for person_nbr before selecting rows:
\prompt 'Enter person_nbr: ' store
select p.person_nbr, p.lname
On Wed, 22 Jan 2025, David G. Johnston wrote:
The value has a line break break character sequence at that point (I
forget if it has any awareness of CR and CRLF differences…)
David,
Ah! A newline (\n). Thanks very much. I fix the row with an update and now I
understand that the original input
I use scripts to enter new rows in tables yet on rare occasions when I
select all columns from a table I'll find a "+" at the end of a string
value in one column. My web search finds no explanation.
What does that + symbol mean in this context?
TIA,
Rich
On Wed, 18 Dec 2024, Rich Shepard wrote:
Since your column name has an Upper case character, you will have to use
double quotes to drop it. Try alter table statustypes drop column
"Suspect";
Thanks for the lesson.
But,
bustrac=# alter table statustypes drop column "S
On Wed, 18 Dec 2024, David G. Johnston wrote:
Failed to double-quote your column name.
David,
Thanks. That's a new one on me.
Regards,
Rich
On Wed, 18 Dec 2024, Viral Shah wrote:
Since your column name has an Upper case character, you will have to use
double quotes to drop it. Try alter table statustypes drop column "Suspect";
Viral,
Huh! I've not before encountered this in the 30+ years I've used postgres.
Thanks for the lesson
I'm not seeing why postgres won't drop a table's column:
bustrac=# select * from statustypes order by stat_name;
stat_name
Client
Lead
No further contact
Opportunity
Proposal submitted
Prospect
Qualified
Referral
Suspect
(9 rows)
bustrac=# alter table statust
On Fri, 13 Dec 2024, Adrian Klaver wrote:
Alright, from here:
https://www.postgresql.org/docs/current/app-pgdump.html
"-c
--clean
Output commands to DROP all the dumped database objects prior to
outputting the commands for creating them. This option is useful when the
restore is to overw
On Fri, 13 Dec 2024, Rich Shepard wrote:
#!/usr/bin/bash
The line was separated.
Rich
On Fri, 13 Dec 2024, Adrian Klaver wrote:
This needs more information:
1) Have you backed up your database at the current state?
Adrian,
No, the current state is FUBAR'd. The cron backup script runs each night at
11:15 p.m.
2) What command did you use to create bustrac-2024-12-12.sql?
!/
On Fri, 13 Dec 2024, Ron Johnson wrote:
It's a text file. Open it up, and see if there's a DROP DATABASE in there.
Ron,
No `drop database' but it drops constraints and tables. I could add a drop
database to the backup script after restoring yesterday's status.
Thanks,
Rich
I made a careless error this morning and want to restore the database from
yesterday's backup, `bustrac-2024-12-12.sql'. If I run
psql -d bustrac -f bustrac-2024-12-12.sql
will this restore the database to yesterday's status without first
deleting/removing the FUBAR'd one?
TIA,
Rich
On Tue, 22 Oct 2024, Rossana Ocampos wrote:
ERROR: invalid input syntax for type date: "CURRENT_DATE" LINE 1:
...extsupplydate ('1085018'::bigint, '5278'::bigint, 'CURRENT_D... ^ ERROR:
invalid input syntax for type date: "CURRENT_DATE" SQL status: 22007
Characters: 78
Rossana,
Also, I sugges
On Tue, 22 Oct 2024, Rossana Ocampos wrote:
I am new with PostgreSQL and I have a bug. I have created a function that
has an input variable of type date , in case it does not receive value ,
it has to assume by default the current date.
ERROR: invalid input syntax for type date: "CURRENT_DATE
On Thu, 12 Sep 2024, Adrian Klaver wrote:
Quick and dirty:
people_table
person_id PK
name_last
name_first
email_address
ph_number
...
location_table
loc_id PK
person_id_fk FK <--> people_table(person_id)
loc_name
loc_st_addr
loc_st_city
loc_st_st_prov
...
contact_
On Fri, 13 Sep 2024, Tony Shelver wrote:
Or if you want to get even more flexible, where a dairy could have more
than one owner as well as one owner having more than one dairy, you could
create an intersection / relationship table.
Something like
-- Create people table (one entry per person)
C
On Fri, 13 Sep 2024, Muhammad Usman Khan wrote:
To handle this situation in PostgreSQL, you can model the data in a way
that maintains a single entry for each owner in the people table while
linking the owner to multiple dairies through a separate dairies table.
This is a typical one-to-many rel
On Thu, 12 Sep 2024, Adrian Klaver wrote:
Quick and dirty:
people_table
person_id PK
name_last
name_first
email_address
ph_number
...
location_table
loc_id PK
person_id_fk FK <--> people_table(person_id)
loc_name
loc_st_addr
loc_st_city
loc_st_st_prov
...
contact_
On Thu, 12 Sep 2024, David G. Johnston wrote:
Read up on “many-to-many” data models. In SQL they involve a linking
table, one row per bidirectional edge, in addition to the two node tables.
David,
Thanks very much. I knew about those a long time ago but haven't needed them
in a long time so I
I have one name in the people table who owns 5 different dairies with three
different phone numbers, but all 5 have the the same email address.
The five dairies each has its own name and location while the people table
has five rows with the same last and first names and email address.
Is there
On Thu, 12 Sep 2024, Muhammad Usman Khan wrote:
You can try the following CTE which removes all the identical rows and only
leave single row
Thank you, Muhammed.
Rich
On Tue, 10 Sep 2024, Rich Shepard wrote:
to see how big a problem it is. If it is only a few projects it could just
a matter of manually deleting the extras.
Not knowing how to do that is why I wrote.
A web search (which I should have done before posting this thread) shows me
how to do
On Tue, 10 Sep 2024, Adrian Klaver wrote:
You might want to do something like:
select proj_nbr, count(*) as ct from projects group by proj_nbr;
to see how big a problem it is. If it is only a few projects it could just a
matter of manually deleting the extras.
Adrian,
It's a small table, n
On Tue, 10 Sep 2024, Andreas Kretschmer wrote:
you can use the hidden ctid-column:
postgres=# create table demo (id int, val text);
CREATE TABLE
postgres=# insert into demo values (1, 'test1');
INSERT 0 1
postgres=# insert into demo values (1, 'test1');
INSERT 0 1
postgres=# insert into demo va
On Tue, 10 Sep 2024, Christophe Pettus wrote:
If you don't mind taking the time to swap tables, you can always do an
INSERT ... SELECT DISTINCT into a new table, and then swap it
with the existing table.
Christophe,
I'll make the proj_nbr table the PK then do as you recommend.
Thank you,
R
On Tue, 10 Sep 2024, Francisco Olarte wrote:
Do you have any kid of corruption (i.e, unique index violation) or is
it just a duplicate problem?
Francisco,
Only a duplicate problem because when I created this table I didn't make the
proj_nbr column a PK.
Also, if you do not have any uniquene
On Tue, 10 Sep 2024, Adrian Klaver wrote:
Is there a Primary Key or Unique index on this table?
Adrian,
No. It didn't occur to me to make the project number a PK as this table is
not related to others in the database.
But, yesterday it occurred to me to make the proj_nbr a PK to eliminate
fu
I've no idea how I entered multiple, identical rows in a table but I want to
delete all but one of these rows.
Here's an example:
bustrac=# select * from projects where proj_nbr = '4242.01';
proj_nbr | proj_name| start_date | end_date | description | notes
--+
On Wed, 10 Jul 2024, Rob Sargent wrote:
I'm an emacs user too. Do you have show-paren enabled? This would show
that your file was ill-formed. M-p and M-n go previous/next matching
parentheses of all types.
Rob,
No, I haven't enabled show-paren.
Thanks for the tip,
Rich
On Wed, 10 Jul 2024, David G. Johnston wrote:
My first easy look for this setup is for any single quotes not adjacent to
either a comma or a parenthesis. Syntax highlighting should ideally have
caught this but I’d look anyway.
David,
I found an error on line 21 that I missed seeing every tim
On Wed, 10 Jul 2024, Hans Schou wrote:
If the file has these line breaks you show, then can make it to multiple
'INSERT INTO' instead.
Hans,
I thought of that, but forgot it. This makes more sense than dividing the
file in small chunks.
Thanks,
Rich
On Wed, 10 Jul 2024, David G. Johnston wrote:
And what are the first few lines of the file? Use text, not screenshots.
David,
insert into locations
(company_nbr,loc_nbr,loc_name,addr1,city,state_code,postcode) values
(2564,1,default,'4250 Hopkins Rd','Ontario','OR','97914'),
(2565,1,default,
On Tue, 9 Jul 2024, Craig McIlwee wrote:
The input file is 488 lines (presumably, since Rich said the file should
insert 488 rows). It seems like too much of a coincidence that the last
character of the last line is really the error. My guess is that there is
an unmatched character, perhaps a pa
On Tue, 9 Jul 2024, Adrian Klaver wrote:
The error:
LINE 488: ...2832,1,default,'85250 Red House Rd','Paisley','OR','97636')
is giving you the line number and the data:
a) Navigate to that line number using whatever method Joe has for that.
b) Search for '85250 Red House Rd'.
Adrian,
With t
On Tue, 9 Jul 2024, Rich Shepard wrote:
Should I run BEGIN: at the psql prompt prior to entering the insert
command? Would that tell me if any rows were entered and, if so, where
that stopped?
Began a transction, ran the script, checked the locations table for a couple
of rows to be inserted
On Tue, 9 Jul 2024, Adrian Klaver wrote:
bustrac=#\e scripts/insert-addrs.sql 488
If that raises this error:
environment variable PSQL_EDITOR_LINENUMBER_ARG must be set to specify a line
number
Adrian,
It doesn't; it prints the contents of the file to the virtual terminal.
Using my default s
On Tue, 9 Jul 2024, Ray O'Donnell wrote:
Did you run the entire thing inside a transaction? If so, then it will have
been rolled back after the error, and no rows will have been inserted.
Ray,
When I tried using transactions they froze the application. Probably because
I don't know to properl
I've a file with 488 rows to be input into a table. I run the script using
psql with the `\i' option.
After psql found a few missing commas I thought the script was clean. But,
psql returned this error:
bustrac=# \i scripts/insert-addrs.sql
psql:scripts/insert-addrs.sql:488: ERROR: syntax error
On Wed, 3 Jul 2024, Adrian Klaver wrote:
alter table array_conv alter column email type varchar[] using array[email];
select * from array_conv ;
id |email
+-
1 | {adrian.kla...@aklaver.com}
2 | {akla...@example.com}
Adrian,
Given my inexperience
On Wed, 3 Jul 2024, David G. Johnston wrote:
Yeah, the simply cast suggested will not work. You’d have to apply an
expression that turns the current contents into an array. The current
contents are not likely to be an array literal.
David,
No, it's not now an array.
I thought that this expre
On Wed, 3 Jul 2024, Rich Shepard wrote:
What I've tried:
bustrac=# alter table people alter column email set data type varchar(64) [];
ERROR: column "email" cannot be cast automatically to type character
varying[]
HINT: You might need to specify "USING email::
On Tue, 2 Jul 2024, Christophe Pettus wrote:
To be clear, I wasn't suggesting stuffing them all into a text column with
a delimiter, but storing them in a text *array* field, each email address
one component of the array.
Christophe,
I'm not using the proper syntax and the postgres alter tabl
On Tue, 2 Jul 2024, Christophe Pettus wrote:
To be clear, I wasn't suggesting stuffing them all into a text column with
a delimiter, but storing them in a text *array* field, each email address
one component of the array.
Okay. I've not before done that and will learn how. This data set is the
On Tue, 2 Jul 2024, Christophe Pettus wrote:
If you are absolutely 100% sure there will never be any metadata
associated with each email address (like a "valid" flag), you can use
TEXT[] array to store them. Otherwise, it's best to move them into a table
with a foreign key back to the owning rec
In data made available from a state regulatory agency I find a few instances
where a facility contact has two email addresses. While multiple locations
are accommodated because they're in a table separate from the facility name
and details, all people associated with a facility and location are in
On Thu, 20 Jun 2024, Adrian Klaver wrote:
From one of my previous posts(modified):
At this point I think you need to create a simple test case where:
1) You have script with
BEGIN;
COMMIT; --optional
2) In psql do \i
3) Do what you did before to 'recover' from the error.
Shows us the conte
On Thu, 20 Jun 2024, Rob Sargent wrote:
Is psql running in emacs (which is my preferred sql shell. M-x sql-postgres)?
Rob,
Not when I'm entering new data or updating existing tables. Otherwise, yes.
Regards,
Rich
On Wed, 19 Jun 2024, Ron Johnson wrote:
In addition, manually run the "BEGIN;" before the "\i insert-blarge.sql"
command.
That way, insert-blarge.sql just inserts. My reasoning: since you control
the ROLLBACK, you should also control the BEGIN.
Ron,
Hadn't thought of doing that, but now will
On Thu, 20 Jun 2024, Karsten Hilbert wrote:
Shot in the dark: are you be any chance using tab-completion
when running the SELECT before the COMMIT ?
Karsten,
Nope. I prepare DDL, DML, and DQL scripts in emacs, then run them from the
psql prompt using \i .
Regards,
Rich
On Wed, 19 Jun 2024, Ron Johnson wrote:
The problem is that you don't know where it's failing.
Ron,
True that. There's no specificity to why the transaction didn't complete.
I suggest you run "\echo all" before running "\i
insert-law-offices-addr.sql". That way, you'll see which line it b
On Wed, 19 Jun 2024, Adrian Klaver wrote:
I should have added to previous post:
What is the exact command string you are using to launch psql?
$ psql bustrac
Rich
On Wed, 19 Jun 2024, Adrian Klaver wrote:
It shouldn't:
cat transaction_test.sql
BEGIN;
insert into transaction_test values(1, 'test'), (2, 'dog'), (3, 'cat');
test=# create table transaction_test(id integer, fld_1 varchar);
test=# \i transaction_test.sql
BEGIN
INSERT 0 3
test=*# commit ;
CO
On Wed, 19 Jun 2024, Adrian Klaver wrote:
Looks to me you have a left over unresolved transaction in your psql session.
The easiest solution if that is the case is to exit the session and start a
new session to run the script.
Adrian, et al.:
That's what I've done. This time I commented out
On Wed, 19 Jun 2024, Alban Hertroys wrote:
The error prior to those statements is what you need to look at. That’s
what’s causing the transaction to fail.
Alban/Adrian,
I get the impression that you’re executing shell scripts that run the psql
command-line utility.
That's what I do as I've
On Wed, 19 Jun 2024, Adrian Klaver wrote:
Does it have a COMMIT; at the end?
Adrian,
No. I won't commit until I see the results are as intended.
At this point I think you need to create a simple test case where:
I killed the psql process and restarted it to allow me to work on other
issue
On Wed, 19 Jun 2024, Adrian Klaver wrote:
Are there transaction statements e.g. BEGIN;, COMMIT; in the script?
Adrian,
Yes, each script has BEGIN; on line 1.
Rich
On Wed, 19 Jun 2024, David G. Johnston wrote:
Simplest process, after rollback you fix the problem and start again from
the top of the transaction.
David,
That's what I thought I was doing when I re-entered the command to run the
script. That produced the same error because the transaction wa
On Wed, 19 Jun 2024, Adrian Klaver wrote:
Is this being done in a script fed to psql?
Adrian,
Yes. At the psql prompt I use the \i command to run the script.
Rich
I now insert rows using a transaction. Sometimes psql halts with an error:
ERROR: current transaction is aborted, commands ignored until end of
transaction block
I issue a rollback; command but cannot continue processing. What is the
appropriate way to respond to that error after fixing the syn
On Wed, 19 Jun 2024, Ron Johnson wrote:
"Click select" stops at dash in some ssh clients, but not in others.
That's what drives *my* decision making.
(Also, "%F" is equivalent to "%Y-%m-%d".)
Thanks, Ron.
Rich
On Wed, 19 Jun 2024, David G. Johnston wrote:
If you are doing a custom format dump using .sql as the extension is
objectively wrong. it is correct if you are doing an sql dump, but those
are generally best avoided.
David,
I use the default text format so restoration is by psql.
Rich
On Wed, 19 Jun 2024, Adrian Klaver wrote:
That is your choice, whatever makes sense to you.
Thank you, Adrian.
Regards,
Rich
Is the correct date format for pg_dump
-$(date +%Y-%m-%d).sql
or
--MM-DD.sql
or something else?
TIA,
Rich
On Thu, 13 Jun 2024, Adrian Klaver wrote:
Not with:
Table "public.companies"
[...]
Indexes:
"organizations_pkey" PRIMARY KEY, btree (company_nbr)
That would throw duplicate key errors.
Are you sure that you did not do this on the contacts table as the company FK
back to companies
Two tables have a sequence for the PK. Over time I manually entered the PK
numbers not being aware of applying DEFAULT to generate the next number.
I just tried to set one table's PK sequence to the current max(PK) value
using this expression from a stackexchange thread:
SELECT setval('', , true)
On Thu, 13 Jun 2024, David G. Johnston wrote:
You need to show your work here. As your PK is a number it cannot have a
company name as a value and so this doesn't make sense.
David,
insert into companies (company_nbr,company_name,industry,status) values
(DEFAULT,'new company name','Industry'
On Thu, 13 Jun 2024, Jeremy Smith wrote:
There's no need to specify the column if it has a default value, but
specifying it did not cause the issue that you saw.
Jeremy,
I did not know this. While the reason for the issue shall remain unknown, it
did happen and my update script restored order
On Thu, 13 Jun 2024, David G. Johnston wrote:
There is no way, in the absence of a user trigger, that the above insert
command changed pre-existing rows. And if you cannot reproduce the
behavior you claim to have seen I will continue to just assume you have
faulty memory.
David,
While there m
On Thu, 13 Jun 2024, Ron Johnson wrote:
No need to do that. Just write:
INSERT INTO public.companies (company_name, , industry, status)
VALUES ('Berkshire Hathaway', 'Conglomerate', 'Mumble');
The next value of companies_org_nbr_seq will automatically be taken and
inserted into the table.
On Thu, 13 Jun 2024, David G. Johnston wrote:
Because you specified company_name in the column listing for the things
you are inserting values for. So in column position 2 you must have a
value than can be inserted into the company_name column. It is utterly
immaterial how you specified the valu
On Thu, 13 Jun 2024, Adrian Klaver wrote:
You sure you did not actually do an UPDATE without a WHERE?
Adrian,
Yep. There was no row to update as I was adding a new company.
Regards,
Rich
On Thu, 13 Jun 2024, Ron Johnson wrote:
If the table has a primary key, then the command *should* have failed with
a duplicate key error as soon as the first dupe was discovered.
Ron,
I had manually set the PKs (column: company_nbr) which has a sequence
defined for it when I added about 50 ro
On Wed, 12 Jun 2024, Adrian Klaver wrote:
The 'Examples' section at the bottom of this page:
https://www.postgresql.org/docs/current/sql-insert.html
is a useful resource.
Adrian,
That's good to know. Thank you.
Regards,
Rich
On Wed, 12 Jun 2024, Adrian Klaver wrote:
Assuming 'people_person_nbr_seq' is the sequence attached to person_nbr
and the other DEFAULTs are the column defaults then the syntax would be:
INSERT INTO people
(person_nbr, lname, fname, job_title, company_nbr,loc_nbr, direct_phone,
cell_phone,emai
On Wed, 12 Jun 2024, Rob Sargent wrote:
Add "begin;" to that and try it. If you don't get exactly UPDATE 295
reported, then "rollback;";
Got it, thanks.
Rich
On Wed, 12 Jun 2024, Ron Johnson wrote:
A plain UPDATE might work.
UPDATE to_be_updated a
SET bool_col = true
FROM other_table b
WHERE a.pk = b.pk
AND b.field3 = mumble;
(You can join them, right?)
Thanks, Ron.
Rich
On Wed, 12 Jun 2024, David G. Johnston wrote:
INSERT INTO people (person_nbr
DEFAULT('people_person_nbr_seq'),lname,fname,job_title DEFAULT
'Contact',company_nbr,loc_nbr,direct_phone,cell_phone,email,active
DEFAULT('true')) VALUES
https://www.postgresql.org/docs/current/sql-insert.html
Not s
On Wed, 12 Jun 2024, David G. Johnston wrote:
I'll often just use a spreadsheet to build the 295 update commands and
copy-paste them into psql or whatnot.
David,
I'll create and use a temporary table.
Thanks,
Rich
On Wed, 12 Jun 2024, Rich Shepard wrote:
VALUES (nextval('people_person_nbr_seq'), ...
Correction.
Rich
On Thu, 13 Jun 2024, Muhammad Salahuddin Manzoor wrote:
You can use Temporary table. You could create a temporary table with one
column containing the condition values and then use it to update your main
table. This approach can be more flexible and cleaner than writing a
script with multiple up
I have a table with 3492 rows. I want to update a boolean column from
'false' to 'true' for 295 rows based on the value of another column.
Is there a way to access a file with those condition values? If not, should
I create a temporary table with one column containing those values, or do I
write
I have > 100 rows to add to a table using INSERT INTO statements. I want the
PK to be the next value in the sequence. Would this be the appropriate
syntax for the columns to be entered?
INSERT INTO people (person_nbr
DEFAULT('people_person_nbr_seq'),lname,fname,job_title DEFAULT
'Contact',compa
On Mon, 10 Jun 2024, Christophe Pettus wrote:
The sequence functions are documented here:
https://www.postgresql.org/docs/current/functions-sequence.html
setval is the function you want. You can use a SELECT so you don't have to
copy values around:
select setval('t_pk_seq', (sele
On Mon, 10 Jun 2024, David G. Johnston wrote:
For efficiency the only thing used to determine the next value of a
sequence is the stored value of the last sequence value issued. Where that
value may have been used, in a table as a PK or some other purpose, does
not enter into it. Using a sequenc
1 - 100 of 500 matches
Mail list logo
