Alvaro Herrera wrote:
> On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
>
> > Neil Conway wrote:
> > > This patch adds a new GUC var, "default_use_oids", which follows the
> > > proposal for eventually deprecating OIDs on user tables that I posted
> > > earlier to pgsql-hackers. pg_
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I see we still are dumping CREATE TABLE using WITH OIDS, rather than
> > using the more portable SET default_with_oids. This needs fixing.
>
> Yes, I know. If you're eager for it, please consider implementing it
> yourself.
Or I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see we still are dumping CREATE TABLE using WITH OIDS, rather than
> using the more portable SET default_with_oids. This needs fixing.
Yes, I know. If you're eager for it, please consider implementing it
yourself.
-Neil
---(
I see we still are dumping CREATE TABLE using WITH OIDS, rather than
using the more portable SET default_with_oids. This needs fixing.
---
Alvaro Herrera wrote:
> On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrot
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Also, I think we have to have a SET before every CREATE TABLE.
>
> No, only when the value changes from last time. This is not rocket
> science, it's the way pg_dump handles SETs already.
Yea, that was my point of SET SESSION AUTHOR
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm sure there are other ways to phase out OIDs in dumps.
Okay, fair enough -- I'll submit a patch to change this.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
If I want to develop a portable application or I want to port an
application, then I am of course only going to use portable constructs,
that is, tables and views, and possibly sequences. I'm not talking theory
here -- I've actually done it and made several changes to pg_dump along
the way to make
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, I think we have to have a SET before every CREATE TABLE.
No, only when the value changes from last time. This is not rocket
science, it's the way pg_dump handles SETs already.
regards, tom lane
---
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > I'm really not sure we do: the SQL produced by pg_dump was totally
> > non-portable before,
>
> Significant effort has been invested to make pg_dump output portable, and
> I've not had any problems with it last time I tried it. Please explain
>
Peter Eisentraut wrote:
> If I want to develop a portable application or I want to port an
> application, then I am of course only going to use portable constructs,
> that is, tables and views, and possibly sequences. I'm not talking theory
> here -- I've actually done it and made several changes
Christopher Kings-Lynne writes:
> > Significant effort has been invested to make pg_dump output portable, and
> > I've not had any problems with it last time I tried it. Please explain
> > why you think it's "totally" non-portable.
>
> Functions, indexes, operators, types, aggregates, users, grou
Significant effort has been invested to make pg_dump output portable, and
I've not had any problems with it last time I tried it. Please explain
why you think it's "totally" non-portable.
Functions, indexes, operators, types, aggregates, users, groups,
databases, inheritance, clustering, col stat
Hum, sorry to be late, but wasn't one of the supposed strenghts of
pg_dump supposed to be that you could take a dump and load it on a
different RDBMS? I haven't tried it so I don't know if it works, but
this patch takes out the ability to do that -- no one else will accept
WITH/WITHOUT OIDS, so th
Neil Conway writes:
> I'm really not sure we do: the SQL produced by pg_dump was totally
> non-portable before,
Significant effort has been invested to make pg_dump output portable, and
I've not had any problems with it last time I tried it. Please explain
why you think it's "totally" non-portab
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We need a solution to this.
I'm really not sure we do: the SQL produced by pg_dump was totally
non-portable before, and it is slightly less portable now. ISTM that
you will almost always need to do some post-processing of pg_dump's
output to have any hop
Peter Eisentraut wrote:
> Alvaro Herrera writes:
>
> > On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
> >
> > > Neil Conway wrote:
> > > > This patch adds a new GUC var, "default_use_oids", which follows the
> > > > proposal for eventually deprecating OIDs on user tables that I pos
Alvaro Herrera writes:
> On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
>
> > Neil Conway wrote:
> > > This patch adds a new GUC var, "default_use_oids", which follows the
> > > proposal for eventually deprecating OIDs on user tables that I posted
> > > earlier to pgsql-hackers. pg
On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
> Neil Conway wrote:
> > This patch adds a new GUC var, "default_use_oids", which follows the
> > proposal for eventually deprecating OIDs on user tables that I posted
> > earlier to pgsql-hackers. pg_dump now always specifies WITH OID
Updated patch applied. Thanks.
---
Neil Conway wrote:
> This patch adds a new GUC var, "default_use_oids", which follows the
> proposal for eventually deprecating OIDs on user tables that I posted
> earlier to pgsql-hacker
Agreed.
---
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > I will try to appl
Bruce Momjian writes:
> 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.
This parameter ought to be called "default_with_oids", to reflect the
actual effect.
>
> -
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.
---
Neil Conway wrote:
> On Fri, 2003-10-10 a
This has been saved for the 7.5 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Neil Conway wrote:
> On Fri, 2003-10-10 at 05:56, Manfred Koizar wrote:
> > On Tue, 30 Sep 2003 20:00:22 -0400, Neil Conwa
On Fri, 2003-10-10 at 05:56, Manfred Koizar wrote:
> On Tue, 30 Sep 2003 20:00:22 -0400, Neil Conway <[EMAIL PROTECTED]>
> wrote:
> >This patch adds a new GUC var, "default_use_oids"
>
> Shouldn't it be honoured by CREATE TABLE AS SELECT ... ?
Good catch. I've attached an updated patch. I also in
On Tue, 30 Sep 2003 20:00:22 -0400, Neil Conway <[EMAIL PROTECTED]>
wrote:
>This patch adds a new GUC var, "default_use_oids"
Shouldn't it be honoured by CREATE TABLE AS SELECT ... ?
This checkin might contain hints to the places that have to be
modified:
2003-01-23 tgl
* src/backend/executor/
This, and the email thead, were added to the queue for 7.5:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Neil Conway wrote:
> This patch adds a new GUC var, "default_use_oids", which follows the
> proposal f
26 matches
Mail list logo
