Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Switching the default is definitely fine with me, but I'd lean towards
>> ripping it out entirely, given that the backend-supplied chunks of stuff
>> are not going to have extra quotes. We always tell people "always quote
>> or ne
Tom Lane writes:
> Ah. But where exactly will you substitute true for 't'? I don't think
> pg_dump necessarily knows enough to apply that transformation.
Sure, it does it already for other types. Look for BITOID in pg_dump.c.
> Switching the default is definitely fine with me, but I'd lean t
On Wed, 2002-08-14 at 18:20, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > > I will vote against this as being a major loss of legibility. Perhaps
> > > we could compromise on controlling it by a GUC variable, though.
> >
> > I was afraid of that, but to pick up the theme of the day, I'm no
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Most of these look like they would break a lot of people --- for
>> example, we can't just arbitrarily change the results of bool_out.
> That wouldn't help anyway. I meant to add code in pg_dump (and possibly
> the rule recompile
Peter Eisentraut wrote:
> > I will vote against this as being a major loss of legibility. Perhaps
> > we could compromise on controlling it by a GUC variable, though.
>
> I was afraid of that, but to pick up the theme of the day, I'm not sure if
> I want to overcomplexify things that much. ;-)
Tom Lane writes:
> Most of these look like they would break a lot of people --- for
> example, we can't just arbitrarily change the results of bool_out.
That wouldn't help anyway. I meant to add code in pg_dump (and possibly
the rule recompiler). That doesn't break anything.
> You mean you'd
Peter Eisentraut wrote:
> I needed to move a PostgreSQL database to another product but I noticed
^^
Surely this is a misprint. ;-)
> that the pg_dump output contains a few artifacts that make the output
> nonportable. Most of these sh
> * Is anyone working on using standard foreign key creation commands
> instead of CREATE CONSTRAINT TRIGGER?
Submitted with the pg_constraint patch, and more recently updated to
match cvs tip. I believe Tom wishes to review this prior to
application.
---(end of broad
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I needed to move a PostgreSQL database to another product but I noticed
> that the pg_dump output contains a few artifacts that make the output
> nonportable. Most of these should be relatively easy to fix.
Most of these look like they would break a
I needed to move a PostgreSQL database to another product but I noticed
that the pg_dump output contains a few artifacts that make the output
nonportable. Most of these should be relatively easy to fix. Here's my
list:
* Boolean values should be dumped as true and false (rather than 't' and
'f'
10 matches
Mail list logo
