Allow pg_dump to dump sequences using NO_MAXVALUE and NO_MINVALUEb

Started by Rod Taylorabout 23 years ago5 messageshackers
Jump to latest
#1Rod Taylor
rbt@rbt.ca

- Move SEQ_MAXVALUE, SEQ_MINVALUE definitions to sequence.h

- Add check in pg_dump to see if the value returned is the max /min
values and replace with NO MAXVALUE, NO MINVALUE.

- Change START and INCREMENT to use START WITH and INCREMENT BY syntax.
This makes it a touch easier to port to other databases with sequences
(Oracle). PostgreSQL supports both syntaxes already.

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Attachments:

dbseqdump.patchtext/x-patch; charset=ISO-8859-1; name=dbseqdump.patchDownload+64-57
#2Gavin Sherry
swm@linuxworld.com.au
In reply to: Rod Taylor (#1)
Re: Allow pg_dump to dump sequences using NO_MAXVALUE and

On 23 Feb 2003, Rod Taylor wrote:

- Move SEQ_MAXVALUE, SEQ_MINVALUE definitions to sequence.h

- Add check in pg_dump to see if the value returned is the max /min
values and replace with NO MAXVALUE, NO MINVALUE.

- Change START and INCREMENT to use START WITH and INCREMENT BY syntax.
This makes it a touch easier to port to other databases with sequences
(Oracle). PostgreSQL supports both syntaxes already.

+       char            bufm[100],
+                               bufx[100];

This seems to be an arbitary size. Why not set it to the actual maximum
length?

Also:

+       snprintf(bufm, 100, INT64_FORMAT, SEQ_MINVALUE);
+       snprintf(bufx, 100, INT64_FORMAT, SEQ_MAXVALUE);

sizeof(bufm), sizeof(bufx) is probably the more
maintenance-friendly/standard way to do it.

Thanks,

Gavin

#3Rod Taylor
rbt@rbt.ca
In reply to: Gavin Sherry (#2)
Re: [HACKERS] Allow pg_dump to dump sequences using NO_MAXVALUE

On Sun, 2003-02-23 at 09:05, Gavin Sherry wrote:

On 23 Feb 2003, Rod Taylor wrote:

- Move SEQ_MAXVALUE, SEQ_MINVALUE definitions to sequence.h

- Add check in pg_dump to see if the value returned is the max /min
values and replace with NO MAXVALUE, NO MINVALUE.

- Change START and INCREMENT to use START WITH and INCREMENT BY syntax.
This makes it a touch easier to port to other databases with sequences
(Oracle). PostgreSQL supports both syntaxes already.

+       char            bufm[100],
+                               bufx[100];

This seems to be an arbitary size. Why not set it to the actual maximum
length?

Also:

+       snprintf(bufm, 100, INT64_FORMAT, SEQ_MINVALUE);
+       snprintf(bufx, 100, INT64_FORMAT, SEQ_MAXVALUE);

sizeof(bufm), sizeof(bufx) is probably the more
maintenance-friendly/standard way to do it.

I changed the code to use sizeof - but will wait for a response from
Peter before changing the size. It's consistent throughout the sequence
code to be 100 for this purpose.

http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/sequence.c.diff?r1=1.85&amp;r2=1.86

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Attachments:

dbseqdump.patchtext/x-patch; charset=ISO-8859-1; name=dbseqdump.patchDownload+88-81
#4Bruce Momjian
bruce@momjian.us
In reply to: Rod Taylor (#3)
Re: [HACKERS] Allow pg_dump to dump sequences using NO_MAXVALUE

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Rod Taylor wrote:
-- Start of PGP signed section.

On Sun, 2003-02-23 at 09:05, Gavin Sherry wrote:

On 23 Feb 2003, Rod Taylor wrote:

- Move SEQ_MAXVALUE, SEQ_MINVALUE definitions to sequence.h

- Add check in pg_dump to see if the value returned is the max /min
values and replace with NO MAXVALUE, NO MINVALUE.

- Change START and INCREMENT to use START WITH and INCREMENT BY syntax.
This makes it a touch easier to port to other databases with sequences
(Oracle). PostgreSQL supports both syntaxes already.

+       char            bufm[100],
+                               bufx[100];

This seems to be an arbitary size. Why not set it to the actual maximum
length?

Also:

+       snprintf(bufm, 100, INT64_FORMAT, SEQ_MINVALUE);
+       snprintf(bufx, 100, INT64_FORMAT, SEQ_MAXVALUE);

sizeof(bufm), sizeof(bufx) is probably the more
maintenance-friendly/standard way to do it.

I changed the code to use sizeof - but will wait for a response from
Peter before changing the size. It's consistent throughout the sequence
code to be 100 for this purpose.

http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/sequence.c.diff?r1=1.85&amp;r2=1.86

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#5Bruce Momjian
bruce@momjian.us
In reply to: Rod Taylor (#3)
Re: [HACKERS] Allow pg_dump to dump sequences using NO_MAXVALUE

Patch applied. Thanks.

---------------------------------------------------------------------------

Rod Taylor wrote:
-- Start of PGP signed section.

On Sun, 2003-02-23 at 09:05, Gavin Sherry wrote:

On 23 Feb 2003, Rod Taylor wrote:

- Move SEQ_MAXVALUE, SEQ_MINVALUE definitions to sequence.h

- Add check in pg_dump to see if the value returned is the max /min
values and replace with NO MAXVALUE, NO MINVALUE.

- Change START and INCREMENT to use START WITH and INCREMENT BY syntax.
This makes it a touch easier to port to other databases with sequences
(Oracle). PostgreSQL supports both syntaxes already.

+       char            bufm[100],
+                               bufx[100];

This seems to be an arbitary size. Why not set it to the actual maximum
length?

Also:

+       snprintf(bufm, 100, INT64_FORMAT, SEQ_MINVALUE);
+       snprintf(bufx, 100, INT64_FORMAT, SEQ_MAXVALUE);

sizeof(bufm), sizeof(bufx) is probably the more
maintenance-friendly/standard way to do it.

I changed the code to use sizeof - but will wait for a response from
Peter before changing the size. It's consistent throughout the sequence
code to be 100 for this purpose.

http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/sequence.c.diff?r1=1.85&amp;r2=1.86

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073