regression=# select oid from pg_cast;
oid
---
16420
16421
16422
16423
16424
... etc ...
It would be a very serious design error if pg_cast didn't have OIDs,
because then pg_cast entries couldn't have dependency entries in
pg_depend.
OK. Weird. I could have _sworn_ I tried that and I d
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is it true to say that it's impossible for me to allow comments on
> casts, as there is no OID on the pg_cast table?
Eh?
regression=# select oid from pg_cast;
oid
---
16420
16421
16422
16423
16424
... etc ...
It would be a very s
I just noticed this fairly silly behaviour:
test=# select to_char(current_date, 'D'), extract(dow from current_date);
to_char | date_part
-+---
3 | 2
(1 row)
I guess we can't change that now, but they really should number their
days from the same base...
Chris
Hey guys,
Is it true to say that it's impossible for me to allow comments on
casts, as there is no OID on the pg_cast table?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Sun, 2003-10-12 at 05:42, ivan wrote:
> Hi, How can i check how many tules has my declared cursor ?
You can't know the # of tuples produced by a query without producing its
entire result set. Since DECLARE doesn't actually evaluate the query you
specify (... which is the whole point of using cu
Bruce Momjian wrote:
Tatsuo Ishii wrote:
> Yes. I don't think that 2PC is a solution for robustness in face of
> network failure. It's too slow, to begin with. Some sort of
> multi-master system is very desirable for network failures, &c., but
> I don't think anybody does active/hot standby wit
Rod Taylor wrote:
On Mon, 2003-10-13 at 21:26, Jan Wieck wrote:
Why do people wait until the EMT cannot give the life-saving infusion
any more before they realize that "invincible" isn't that great at all?
Some dumb-user/fat-finger/ooops protection is surely welcome, but there
is a limit. A sys
On Monday 13 October 2003 20:11, Rod Taylor wrote:
> > I think another way it could be handled is with nested transactions.
> > Just have the promise phase be an inner transaction commit but have an
> > outer transaction bracket that one for the actual commit.
>
> Not really. In the event of a cras
On Mon, 2003-10-13 at 21:26, Jan Wieck wrote:
> Rod Taylor wrote:
> >> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> >> >> > constraints/triggers, not settable from postgresql.conf?
> >> >>
> >> >> Is that one really necessary for 7.4 now that adding foreign keys i
Rod Taylor wrote:
>> > Allow superuser (dba?) the ability to turn off foreign key checks/all
>> > constraints/triggers, not settable from postgresql.conf?
>>
>> Is that one really necessary for 7.4 now that adding foreign keys is
>> apparently much faster?
If you reconfigure your systems to fo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I think we could allow users to set the transaction isolation level to
> READ UNCOMMITTED or REPEATABLE READ and internally behave like READ
> COMMITTED or SERIALIZABLE, respectively. The SQL standard seems to allow
> this:
My reading is that the spe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We've been using it for awhile, and it's not broken anything. Why are
>> you so eager to make build changes with potentially wide ramifications
>> so late in the beta cycle?
> I don't know what the ramifications of _GNU_SOURCE are, bu
Done as you suggested.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, patch attached and applied. It centralizes the optimization
> > defaults into configure.in, rather than having CFLAGS= in the te
Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I vote to disable the checks for pg_restore if the dumpfile has a check
> > added to ensure it's the same file that was dumped (an MD5 in the
> > header) and it is a full database restore.
> > Individual table restores should require the
Rod Taylor <[EMAIL PROTECTED]> writes:
> I vote to disable the checks for pg_restore if the dumpfile has a check
> added to ensure it's the same file that was dumped (an MD5 in the
> header) and it is a full database restore.
> Individual table restores should require the check.
It is not our busi
Tom Lane wrote:
Seth Ladd <[EMAIL PROTECTED]> writes:
My Table Columns (all bigints): start, stop, step1, step2, step3
^^^
The Query: explain analyze select * from path where start = 653873 or
start = 649967 or stop = 653873 or stop = 649967
Does anyone have a sug
> I think another way it could be handled is with nested transactions.
> Just have the promise phase be an inner transaction commit but have an
> outer transaction bracket that one for the actual commit.
Not really. In the event of a crash, most 2PC systems will expect the
participant to come back
> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> >> > constraints/triggers, not settable from postgresql.conf?
> >>
> >> Is that one really necessary for 7.4 now that adding foreign keys is
> >> apparently much faster?
> If you reconfigure your systems to force fs
Greg Stark <[EMAIL PROTECTED]> writes:
> This is sort of interesting. It seems the time required for the optimizer to
> handle a query doubles with every layer of subquery it has to dig through.
Seems to be due to some brain fade in pull_up_subqueries --- the thing
was constructing truly monstrous
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
> Changes
> ---
> Allow superuser (dba?) the ability to turn off foreign key checks/all
> constraints/triggers, not settable from postgresql.conf?
Is that one really necessary for 7.4 now that adding foreign keys is
apparently much faster?
[ back from San Jose, catching up on email ]
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is that enough feedback? :-)
Yup, thanks for the comments. I am not sure how much of the existing
--help-config functionality is actually needed by Red Hat's tool, so
I've asked those guys to respond.
Pers
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, patch attached and applied. It centralizes the optimization
> defaults into configure.in, rather than having CFLAGS= in the template
> files.
I think there's a problem here:
> + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc
>
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> Tom, you had mentioned adding a delay of some kind to the fsync logic, and
> I'd be more than willing to try out any patch you'd like to toss out to me
> to see if we can get a semi-stable behaviour out of IDE drives with the
> -W1 and -f switches tu
Bruce Momjian writes:
> Let's remove it.
It's gone.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that
This is sort of interesting. It seems the time required for the optimizer to
handle a query doubles with every layer of subquery it has to dig through.
There's a reason I stopped at 2.7s though. When I tried to go one step further
expecting it to take 5s my machine simply froze. It still pinged,
Michael Meskes writes:
> That's it! I'm using ash as sh.
I tried it with ash 0.2 and initdb works fine.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
Michael Meskes <[EMAIL PROTECTED]> writes:
>>> I just tried the latest Debian packages for beta4 and I still cannot
>>> initdb. It's the same old problem. Once I add a "\." to sql_features.txt
>>> it works well, but without it it errors out.
I have fixed this (I hope) using the approach Peter sug
Le Lundi 13 Octobre 2003 21:28, Dave Page a écrit :
> No more so than would be required under the Data Protection Act in the
> UK, but as the project and pgsql.com servers are neither in France or
> the UK, the content on them doesn't have to comply with those laws.
RedHat is a French company in F
> -Original Message-
> From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 11, 2003 5:36 AM
> To: Dann Corbit
> Cc: Christopher Browne; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 2-phase commit
>
>
> On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote:
>
> -Original Message-
> From: Hannu Krosing [mailto:[EMAIL PROTECTED]
> Sent: 13 October 2003 18:00
> To: [EMAIL PROTECTED]
> Cc: PostgreSQL Development
> Subject: Re: [HACKERS] http://www.pgsql.com/register/submit.php
>
> Do we need special NOTICE for French users telling them "In
> c
Jean-Michel POURE kirjutas E, 13.10.2003 kell 16:20:
> Le Lundi 13 Octobre 2003 14:45, Robert Treat a écrit :
> > Someone could have downloaded the package from sourceforge/freshmeat, so
> > I don't think it hurts to have a pointer to postgresql.org. What might
> > be better than a link for the su
Went smooth as a babies bottom ... or, at least from the visible side of
things ... lists should all be working, DNS might take a bit of time to
propogate, but, other then that ... if anyone notices any problems (as
relates to the move) please let me know ...
---(end of
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I was inder the impression, perhaps incorrectly, the casting the pointers to
(void *) would inhibit the compiler from making any assumptions about what
it pointed to, and hence inhibit bad effects from those assumptions. The
only way
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I was inder the impression, perhaps incorrectly, the casting the pointers to
> (void *) would inhibit the compiler from making any assumptions about what
> it pointed to, and hence inhibit bad effects from those assumptions. The
> only way to know woul
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > However, I think the message is a bit pointless altogether.
>
> You have a point. Anyone against ripping it out entirely? If so,
> what needs to be said in this message?
Let's remove it.
--
Bruce Momjian
Le Lundi 13 Octobre 2003 14:45, Robert Treat a écrit :
> Someone could have downloaded the package from sourceforge/freshmeat, so
> I don't think it hurts to have a pointer to postgresql.org. What might
> be better than a link for the submit page would just be a blurb
> mentioning we're always loo
Robert Treat writes:
> Someone could have downloaded the package from sourceforge/freshmeat, so
> I don't think it hurts to have a pointer to postgresql.org.
Those two places already have prominent links to the home page.
> What might
> be better than a link for the submit page would just be a b
On Mon, 2003-10-13 at 00:23, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > However, I think the message is a bit pointless altogether.
>
> You have a point. Anyone against ripping it out entirely? If so,
> what needs to be said in this message?
>
Someone could have downloa
[moved to hackers]
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
>
> I don't think we understand the dangers quite yet, and I think the
> patches applied to date constitute useless thrashing rather than fixes.
> I'd like to see less quick-hack patching and more discussion.
>
39 matches
Mail list logo
