I'd prefer it if OWNER TO were only added if it is actually necessary
(or there be some option to turn it off). I don't want to edit the
entire dump file if I want to restore the database into another SQL
database.
There is the existing --no-owner option, which this patch respects, same
as old
That might change the precedence of the operator and get you in a big
mess with stored expressions everywhere.
What if you could only do it on non-system operators?
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unre
Christopher Kings-Lynne wrote:
> * Is there any reason there is no RENAME TO command for operators?
That might change the precedence of the operator and get you in a big
mess with stored expressions everywhere.
---(end of broadcast)---
TIP 3: if p
Christopher Kings-Lynne wrote:
> Then I made it so that pg_dump will output an OWNER TO statement
> after every object creation.
I'd prefer it if OWNER TO were only added if it is actually necessary
(or there be some option to turn it off). I don't want to edit the
entire dump file if I want to
In line with my idea of keeping the hackers up to date with stuff in the
IRC channel, here are the topics of the week:
* We have a request for granting on all tables every other day (already
in TODO)
* We have a request for how to change database encoding every other day
(i suggest a warning
So that the initial owner is still owner when he does COPY, ALTER TABLE
ADD PRIMARY KEY, etc etc. Else you're gonna have problems.
I was thinking of doing all COPY and ALTER as superuser as well...
Or are you trying to make it work when run as non-super? Which is won't
since ALTER OWNER will req
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I just inserted the ALTER OWNER statement between the CREATE and the
> GRANTs. Why do you want them at the end of the dump?
So that the initial owner is still owner when he does COPY, ALTER TABLE
ADD PRIMARY KEY, etc etc. Else you're gonna h
Perhaps better to put these out towards the end of the dump, not right
after the creation of the object? Or is that what you're doing?
I just inserted the ALTER OWNER statement between the CREATE and the
GRANTs. Why do you want them at the end of the dump?
I would envision the safest procedure
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> got everything built this evening, just giving it a bit of time to
> propogate out to the mirrors before announcing ...
Final tarball looks good from here ... but don't forget to update
the symlinks at the top level of the ftp site.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am not 100% excited about the memory
> part because it invalidates all register memory values, not just the
> shared memory location.
That's exactly the point.
> We are specifically accessing a memory address
> as part of the ASM, so I don't see how i
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Then I made it so that pg_dump will output an OWNER TO statement after
> every object creation.
Perhaps better to put these out towards the end of the dump, not right
after the creation of the object? Or is that what you're doing?
I would en
Dave Cramer <[EMAIL PROTECTED]> writes:
> I am getting the following error:
> error: parse error in expression
What does this have to do with accelerating aggregates?
Please don't start new threads by responding to existing threads.
--
greg
---(end of broadcast)-
Hi,
This is a preview patch - DON'T COMMIT IT TO HEAD!
What I've done in this patch is add the following:
ALTER AGGREGATE / OWNER TO
ALTER CONVERSION / OWNER TO
ALTER FUNCTION / OWNER TO
ALTER OPERATOR / OWNER TO
ALTER OPERATOR CLASS / OWNER TO
ALTER SCHEMA / OWNER TO
ALTER TYPE / OWNER TO
That mea
Not any better than it does now, no ... but AFAIK simple cases work okay
on that. What's your gripe exactly?
No gripe - was just pointing out a situation that might be improved
slightly be carrying around typmod info.
Chris
---(end of broadcast)---
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Does that help with making CREATE TABLE AS SELECT pick up varchar
> lengths, etc.?
Not any better than it does now, no ... but AFAIK simple cases work okay
on that. What's your gripe exactly?
regards, tom lane
--
Sounds good to me. Consistencyis important because it lets us fix
problems across all cpu types. I am not 100% excited about the memory
part because it invalidates all register memory values, not just the
shared memory location. We are specifically accessing a memory address
as part of the ASM,
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
But there are still other expression trees
that would benefit, e.g. those involving an IMMUTABLE function with
parameterized arguments.
Oh, you are thinking of some very-long-lived cache. This has been
proposed and rejected before; it's j
Now that cast functions are selected through pg_cast, this should be a
fairly straightforward change. Does anyone have a problem with it?
I'm not sure the functionality is actually useful for anything except
this one issue, but arguably it's a general-purpose mechanism...
Does that help with makin
got everything built this evening, just giving it a bit of time to
propogate out to the mirrors before announcing ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
I am getting the following error:
error: parse error in expression
error: /usr/src/redhat/SPECS/postgresql-7.4.2-1PGDG.spec:98:
parseExpressionBoolean returns -1
error: Package has no %description: postgresql
When I execute
rpmbuild --rebuild --define 'build9x 1' --define 'tcldevel 0' --define
A very minor rant.
I usually run 7.4.1 at home, but today I need to do some testing on
7.2.1 so I downgraded my RPM installation. When trying to start
postgresql with /etc/init.d/postgresql, it fails with this message:
"An old version of the database format was found.\nYou need to upgrade
the d
Steve Atkins <[EMAIL PROTECTED]> writes:
> On Fri, Jun 11, 2004 at 12:17:57PM -0400, Greg Stark wrote:
>
> > no, read committed would see any other updates that have been committed since
> > the start of your transaction.
>
> Uhm... only updates within the current transaction.
No, "read commit
Pursuant to the gripes raised by Martin Pitt ---
I've consulted some gcc experts within Red Hat and come to the following
conclusions:
* We should consistently refer to the spinlock contents via a
read/write operand declared like "+m"(*lock). This is consistent
with longstanding practice in the
Hi,
I think replacing the RELOID with TYPEOID should get you the required Datum
...
later you may have to use
Form_pg_type pform = (Form_pg_type) GETSTRUCT(tuple);
to get a reference to the type tuple.
I have worked this way but iam not sure whether this is correct or not !!
If iam wrong some bod
[EMAIL PROTECTED] wrote:
I have been talking about two types of problems which are both based on
PostgreSQL's behavior with frequently updated tables.
Summary table: In the single row table system, you have to vacuum very
requently, and this affects performance.
Frequently updated tables: think abo
> [EMAIL PROTECTED] wrote:
>
>>
>>I have been talking about two types of problems which are both based on
>>PostgreSQL's behavior with frequently updated tables.
>>
>>Summary table: In the single row table system, you have to vacuum very
>>requently, and this affects performance.
>>
>>Frequently up
Oliver Jowett <[EMAIL PROTECTED]> writes:
> But there are still other expression trees
> that would benefit, e.g. those involving an IMMUTABLE function with
> parameterized arguments.
Oh, you are thinking of some very-long-lived cache. This has been
proposed and rejected before; it's just not a
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
I guess that ExprState does not live long enough to be useful.
Actually the opposite: it lasts too long, namely the entire execution of
a query. I don't think there's any convenient way to reset it on the
timescale appropriate for STABLE v
On Mon, 14 Jun 2004, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
The INSTALL file looks quite bad.
It's clearly been freshly generated. The formatting does seem worse
than in previous versions, but it's not so bad I'd want to hold up
the release to fix it.
My guess is that the "wr
Scott Marlowe wrote:
On Fri, 2004-06-11 at 11:02, Bruce Momjian wrote:
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|>Bruce Momjian wrote:
|>
|> > I understand your points below. However
Bruce Momjian wrote:
Tom Lane wrote:
Now that I think about it, I believe Bruce recently removed this on my
advice; I was thinking that the problem shouldn't occur anymore now that
True.
we WAL-log file creation and deletion. But actually the present form of
the WAL entries doesn't ensure that a
Chris K-L's recent complaint reminded me that we had been talking about
redefining int-to-bit(n) casting to take the rightmost n bits of the
integer value, instead of the leftmost n bits. The implementation
reason why it works the way it does is that the existing cast function
effectively converts
Oliver Jowett <[EMAIL PROTECTED]> writes:
> I guess that ExprState does not live long enough to be useful.
Actually the opposite: it lasts too long, namely the entire execution of
a query. I don't think there's any convenient way to reset it on the
timescale appropriate for STABLE values (ie, onc
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is there any reason for this behaviour:
> test=# select 1::bit;
> bit
> -
> 0
> (1 row)
This is actually "1::int4::bit(1)", and what you are getting is
the sign bit. See previous discussions about int-to-bit conversion
and which part o
I wrote:
> My guess is that the "wrong" version of lynx is being used to build it.
> I remember being dissatisfied with the output of developer.pg.org's
> version of lynx back when we were making this file manually.
> (The version I have here is 2.8.5rel.1 (04 Feb 2004) and it seems to
> do fine.)
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm afraid that's not enough. Checkpoints spoil it, think:
> 1. CREATE TABLE foobar ...
> 2. INSERT
> 3.
> 4.
> The replay would not see the file-creation WAL record.
Good point. That makes it messy enough that we probably don't want to
do
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The INSTALL file looks quite bad.
It's clearly been freshly generated. The formatting does seem worse
than in previous versions, but it's not so bad I'd want to hold up
the release to fix it.
My guess is that the "wrong" version of lynx is being use
>
>>The "PostgreSQL Enhanced Server" (How's that name? Maybe we call it
>> Zerver
>>and use PEZ?) idea is how to take the excellent core of PostgreSQL and
>>productize it in much the same way distributions take the Linux kernel
>> and
>>may a GNU/Linux system.
>>
>>
>>
> It would seem to me that th
Magnus Hagander wrote:
What is the recommended way to create mutex objects
(CreateMutex) from
Win32 libraries? There must be a clean way like there is
in pthreads.
A mutex is inherently a global object. CreateMutex(NULL,
FALSE, NULL)
will re
> >>What is the recommended way to create mutex objects
> (CreateMutex) from
> >>Win32 libraries? There must be a clean way like there is
> in pthreads.
> >>
> >>
> >
> >A mutex is inherently a global object. CreateMutex(NULL,
> FALSE, NULL)
> >will return a handle to an unowned mutex.
> >
Joshua D. Drake wrote:
The "PostgreSQL Enhanced Server" (How's that name? Maybe we call it Zerver
and use PEZ?) idea is how to take the excellent core of PostgreSQL and
productize it in much the same way distributions take the Linux kernel and
may a GNU/Linux system.
It would seem to me that t
41 matches
Mail list logo
