Yeah. Don't you think that should preserve comments on large objects,
now that such comments are alleged to be a supported facility?
How does pg_dump dump the blobs?
It dumps them, reloads them (which causes them to be assigned new OIDs)
and then runs around and tries to fix up references to th
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> On Sun, 2003-12-14 at 18:02, Tom Lane wrote:
>> How large N will be in practice remains to be seen, of course, but I'd
>> expect something on the order of 4 or 5.
> Ok, this is what I was looking for. If we are serious about this, would
> it mak
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Oh, okay, it doesn't work.
> Do you mean using pg_dump with the '-b' option?
Yeah. Don't you think that should preserve comments on large objects,
now that such comments are alleged to be a supported facility?
> How does pg_dump dump the bl
How do you mean? pg_dump never writes out the COMMENT ON commands...
Oh, okay, it doesn't work.
Care to think about how to fix that?
I think you're going to have to explain the exact problem to me - I
don't quite get what you mean?
Do you mean using pg_dump with the '-b' option?
How does pg_
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> (Note to self: I wonder whether the recently-added COMMENT ON LARGE
>> OBJECT facility works at all over dump/reload...)
> How do you mean? pg_dump never writes out the COMMENT ON commands...
Oh, okay, it doesn't work.
Care to think about h
Andrew Dunstan wrote:
>
> [moved to hackers / win32]
>
> Claudio Natoli wrote:
>
> >Or do people have strong leanings towards "fix as you go along"? Just feels
> >like that way could see us getting bogged down making things "perfect"
> >instead of advancing the port...
> >
> >
> >
>
> w.r.t.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... Maybe we need a per-backend array in
> > shared memory just for those keys. The postmaster has to keep those
> > keys anyway, so moving into shared memory might be the right solution.
>
> The postmaster's dependence on the conten
No. Large object OIDs are preserved in the given proposal.
(Note to self: I wonder whether the recently-added COMMENT ON LARGE
OBJECT facility works at all over dump/reload...)
How do you mean? pg_dump never writes out the COMMENT ON commands...
Chris
---(end of broadca
On Sun, 2003-12-14 at 18:02, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > How limiting is the above? Does this mean that pg_upgrade will be
> > rendered invalid if there is an on-disk representation change? Do we
> > think we will make it from 7.4 -> 7.5 without on-disk
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Doesn't matter. Catalog entries are dumped and reloaded; there is no
>> carry-forward of OIDs.
> Large objects included?
No. Large object OIDs are preserved in the given proposal.
(Note to self: I wonder whether the recently-added COMMENT ON LARGE
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> If the sort used to select the records sorts on both the distinct
> expressions and the order by expressions you will get a sensible
> deterministic result.
Sensible in what sense? ;-)
It seems to me that the existing documentation defines the behavi
Neil Conway <[EMAIL PROTECTED]> writes:
> Does the non-determinism you're referring to result from an ORDER BY
> on a non-deterministic expression, or the non-determinism that results
> from picking an effectively random row because the ORDER BY isn't
> sufficient?
The latter --- you don't know wh
On Sun, Dec 14, 2003 at 18:09:33 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> This was discussed before --- see the archives. I believe the
> conclusion was that the results would actually be nondeterministic
> if we used two sort steps (that's what the code comment means by
> "rather unpredi
On Sun, Dec 14, 2003 at 09:48:20PM -0500, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > What about cached OIDs in view and function definitions, etc...?
>
> Doesn't matter. Catalog entries are dumped and reloaded; there is no
> carry-forward of OIDs.
>
> I suppose if
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What about cached OIDs in view and function definitions, etc...?
Doesn't matter. Catalog entries are dumped and reloaded; there is no
carry-forward of OIDs.
I suppose if someone were storing OIDs of tables or functions or views
in user tables
Tom Lane <[EMAIL PROTECTED]> writes:
> This was discussed before --- see the archives. I believe the
> conclusion was that the results would actually be nondeterministic
> if we used two sort steps (that's what the code comment means by
> "rather unpredictable").
Does the non-determinism you're r
No. The proposed pg_upgrade procedure doesn't try to reproduce OIDs of
catalog entries (other than toast-table OIDs, which are never
preassigned anyway), so there's no issue.
Good point though --- thanks for thinking about it.
What about cached OIDs in view and function definitions, etc...?
Like
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Will we now have to be careful to NEVER re-use OIDs in the system catalogs.
No. The proposed pg_upgrade procedure doesn't try to reproduce OIDs of
catalog entries (other than toast-table OIDs, which are never
preassigned anyway), so there's no
Per prior discussion, we will enforce some sort of limit on how often
the representation of user tables/indexes can be changed. The idea will
be to "batch" such changes so that you only have to do a dump/reload
every N major releases instead of every one. In other words, pg_upgrade
will work for
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... Maybe we need a per-backend array in
> shared memory just for those keys. The postmaster has to keep those
> keys anyway, so moving into shared memory might be the right solution.
The postmaster's dependence on the contents of shared memory should
i
Greg Stark <[EMAIL PROTECTED]> writes:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
>> I did start by changing all the context's to void *, but you'll
>> loose the real type that it gets called with, so the other calls
>> will not generate warnings anymore because of wrong type.
> But at least you'
[moved to hackers / win32]
Claudio Natoli wrote:
Or do people have strong leanings towards "fix as you go along"? Just feels
like that way could see us getting bogged down making things "perfect"
instead of advancing the port...
w.r.t. Win32, I think the way to proceed is (in this order):
. ma
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> I'm trying to change all the walkers and mutators to have a more
> strict prototype. I had to do this with lots of casts.
Forget it ;-). There's a reason why they use a loose prototype,
and it's exactly what you just found: the notational penalty of
bein
On Fri, Jul 18, 2003 at 10:28:40PM -0300, The Hermit Hacker wrote:
> On Wed, 16 Jul 2003, Alvaro Herrera wrote:
>
> > On Wed, Jul 16, 2003 at 01:57:41PM -0500, Thomas Swan wrote:
> > > Does anyone have recent archives of the pgsql-hackers list in mbx or
> > > flat file format?
> >
> > I really mis
Greg Stark <[EMAIL PROTECTED]> writes:
> So, like DISTINCT ON, GROUP BY also insists on the user providing the
> ORDER BY clause. I suppose you could argue postgres could implicitly
> introduce an extra sort step when the user-provided ORDER BY doesn't
> match the GROUP BY or DISTINCT ON clause but
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
>> [ pg_upgrade won't be able to change user table representation ]
> How limiting is the above? Does this mean that pg_upgrade will be
> rendered invalid if there is an on-disk representation change? Do we
> think we will make it from 7.4 -> 7.5
pgman wrote:
> Neil Conway wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I don't think we ever discussed it, but it seemed logical and a minimal
> > > change to the code. We already have a GUC write of non-default values
> > > for exec and no one had issues with that.
> >
> > For the
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't think we ever discussed it, but it seemed logical and a minimal
> > change to the code. We already have a GUC write of non-default values
> > for exec and no one had issues with that.
>
> For the record, I think that is ug
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> I did start by changing all the context's to void *, but you'll
> loose the real type that it gets called with, so the other calls
> will not generate warnings anymore because of wrong type.
But at least you'll get a warning if someone passes a non-poin
On Sat, Dec 13, 2003 at 22:12:32 -0500,
Greg Stark <[EMAIL PROTECTED]> wrote:
>
> So, like DISTINCT ON, GROUP BY also insists on the user providing the ORDER BY
> clause. I suppose you could argue postgres could implicitly introduce an extra
> sort step when the user-provided ORDER BY doesn't ma
On Sat, Dec 13, 2003 at 10:24:23PM -0500, Greg Stark wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
>
> > I'm trying to change all the walkers and mutators to have a more
> > strict prototype. I had to do this with lots of casts.
> >
> > I don't really like the idea of having all those generic
31 matches
Mail list logo
