Tom Lane wrote:
(B>
(B> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
(B> > The simplest senario(though there could be varations) is
(B>
(B> > [At participant(master)'s side]
(B> > Because the commit operations is done, does nothing.
(B>
(B> > [At coordinator(slave)' side]
(B> >1) Aft
I think the advantages of choice (b) are obvious --- it doesn't allow
bogus data to be loaded accidentally, and it doesn't create a problem
with loading existing 7.3 dump files that don't know how to suppress the
check.
OK, I didn't realise there was a (b). I volunteer to do speed tests on
data
(B
(BHiroshi Inoue wrote:
(B>
(B> Tom Lane wrote:
(B> >
(B> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
(B> > > The simplest senario(though there could be varations) is
(B> >
(B> > > [At participant(master)'s side]
(B> > > Because the commit operations is done, does nothing.
(B> >
(
>From CVS logs I see:
pg_dump/pg_restore now always use SET SESSION AUTHORIZATION, not
\connect, to control object ownership. The
use-set-session-authorization and no-reconnect switches are obsolete
Tom Lane wrote:
(B>
(B> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
(B> > The simplest senario(though there could be varations) is
(B>
(B> > [At participant(master)'s side]
(B> > Because the commit operations is done, does nothing.
(B>
(B> > [At coordinator(slave)' side]
(B> >1) Aft
Hi,
I notice that the pretty printing version of pg_get_ruledef inserts extra
newlines whereas all the others pretty functions (except view defs) do
not. In fact, Andreas argued against a version of pg_get_triggerdef()
that added extra newlines.
eg, non-pretty:
test=# select pg_get_ruledef(oid)
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I think we need someway of telling postgres to suppress a foreign key check.
Well, the subtext argument here is "do we fix it by providing a way to
suppress the check, or do we fix it by making the check fast enough to
be tolerable?"
I think t
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> The simplest senario(though there could be varations) is
> [At participant(master)'s side]
> Because the commit operations is done, does nothing.
> [At coordinator(slave)' side]
>1) After a while
>2) re-establish the communication path between
Christopher Kings-Lynne wrote:
> You could just as easily argue that the lack of integrity testing at
> data load time was equally a bug.
>
> I think we need someway of telling postgres to suppress a foreign key check.
>
> The main problem is that the foreign key column is often not indexed.
As
On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
> The simplest senario(though there could be varations) is
>
> [At participant(master)'s side]
> Because the commit operations is done, does nothing.
>
> [At coordinator(slave)' side]
>1) After a while
>2) re-establish the communication path bet
You could just as easily argue that the lack of integrity testing at
data load time was equally a bug.
I think we need someway of telling postgres to suppress a foreign key check.
The main problem is that the foreign key column is often not indexed.
Chris
Bruce Momjian wrote:
Tom Lane wrote:
I have a few questions (below).
Mechanism:
1) Rename the old column to ...pg.dropped... to get it out of
the way of step 2.
2) Create a new column with the wanted type and appropriate
constraints. Only not null is supported at the moment.
3
Christopher Kings-Lynne wrote:
> If you are referring to my patch, Bruce - that does not fix it. Mine
> only addresses psql.
>
> I don't think that pg_dump uses pg_get_constraintdef(). It's probably a
> side effect of switching from using consrc to conbin.
Oh, yea. If forgot the pretty prin
Hiroshi Inoue wrote:
(B>
(B> > -Original Message-
(B> > From: Tom Lane
(B> >
(B> > Bruce Momjian <[EMAIL PROTECTED]> writes:
(B> > > Tom Lane wrote:
(B> > >> You're not considering the possibility of a transient communication
(B> > >> failure.
(B> >
(B> > > Can't the master re-se
If you are referring to my patch, Bruce - that does not fix it. Mine
only addresses psql.
I don't think that pg_dump uses pg_get_constraintdef(). It's probably a
side effect of switching from using consrc to conbin.
Chris
Bruce Momjian wrote:
I have a fix for this in the patch queue and it w
I have a fix for this in the patch queue and it will be applied in 24
hours. If you want to try it, it is at:
http://momjian.postgresql.org/cgi-bin/pgpatches
---
Bruno Wolff III wrote:
> If you have a check const
On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
> "Marc G. Fournier" wrote:
> >
> > On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
> >
> > > He also ignored my question about "2 phase commit" in pgsql-hackers, for
> > > example.
> >
> > Actually, I've been following that thread pretty closely, and I believ
"Marc G. Fournier" wrote:
(B>
(B> On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
(B>
(B> > He also ignored my question about "2 phase commit" in pgsql-hackers, for
(B> > example.
(B>
(B> Actually, I've been following that thread pretty closely, and I believe I
(B> missed your question :(
(B
If you have a check constraint that tests if a boolean column is not
false by just using the column name, pg_dump doesn't include parens
around the check constraint which causes a syntax error when reloading
the database.
Using the following to create a table:
create table test (col1 boolean const
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If you put it that way :-) I'll leave it alone. I hope it can be
> enhanced in the next release. I'm not sure of it usefulness anyway;
> the documentation seems good enough.
Some guys at Red Hat wanted it to support an admin tool that should see
the l
On Sun, Sep 28, 2003 at 08:09:31PM -0400, Tom Lane wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > In 7.4 I am finding that '(' (and some other punctuation) is not a member of
> > [:print:]. It is in 7.3. It is a member of [:graph:] in 7.4 (which is
> > supposed to be [:print:] - [:space:
On Sun, Sep 28, 2003 at 20:09:31 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> in other words, :print: is the same as :alnum:. This is obviously
> a bug, will fix ... wonder if Henry Spencer knows about it?
The really cute thing is I only found it because I made a mistake.
I didn't want to in
Bruce Momjian wrote:
I like your text much better --- added. I will throw this email in the
7.5 queue and we can decide if it is a bug then.
If is a bug is better have a patch for the 7.4
May be is only a missing feature.
For sure for us was and is actually a nightmare imagine :
V1 -> V2 -> F
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> In 7.4 I am finding that '(' (and some other punctuation) is not a member of
> [:print:]. It is in 7.3. It is a member of [:graph:] in 7.4 (which is
> supposed to be [:print:] - [:space:]).
This is not a locale problem, because I see it in C locale to
On Mon, Sep 29, 2003 at 12:27:01AM +0200, Peter Eisentraut wrote:
> Alvaro Herrera writes:
> > [fixes for --help-config]
> I'm quite unhappy about the --help-config option. It was developed
> without discussion, it was installed hastily, we don't have any
> information about that interactive con
In 7.4 I am finding that '(' (and some other punctuation) is not a member of
[:print:]. It is in 7.3. It is a member of [:graph:] in 7.4 (which is
supposed to be [:print:] - [:space:]).
The following is my 7.4 config:
./configure --prefix=/usr/local/pgsql --enable-integer-datetimes --with-pgport=
Alvaro Herrera writes:
> Oh, there's another thing about the --help-config option. This option
> includes an, er, option to display the items that belong to a given
> group. So you could say
>
> /tmp/pgsql-es/bin/postgres --help-config -g 'Security'
>
> and the list of parameters that belong to
On Sat, 27 Sep 2003, Tom Lane wrote:
> [ continuing a discussion from mid-August ]
>
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> I assume what you have in mind is to replace
> >> validateForeignKeyConstraint() with something that does a join of the
> >> two tables via an SPI command.
>
> > I
On Sun, 28 Sep 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Sat, 27 Sep 2003, Tom Lane wrote:
> >> I thought of what seems to be a better design for the check query: use
> >> a LEFT JOIN and check for NULL in the righthand joined column.
>
> > Hmm, my initial testing sh
Tom Lane wrote:
> > I've actually got code (that no longer cleanly applies, but...) that uses
> > the single query version with NOT EXISTS (which could be easily changed to
> > either of the other forms) and was planning to put it together for a patch
> > when 7.5 devel started because I figured it
Some more comments:
#: utils/misc/guc.c:647
msgid "collect statistics about executing commands"
Is this really "statistics" about the executing commands?
#: utils/misc/guc.c:892
msgid ""
"The number must be a positive integer. If 0 is specified then effort * "
"log2(poolsize) is used"
Is it mi
Joshua D. Drake wrote:
Hello,
Don't know if my vote counts here, but ANYTHING that makes pg_dump
more correct should be
backpatched. It is one thing to have index bloat, it is entirely another
to not be able to correctly backup
and restore.
Patch applied to REL7_3_STABLE.
Jan
Tom Lane wrote:
Stephan Szabo wrote:
> Hmm, my initial testing showed that it really was a little slower
> than a more complicated one with NOT EXISTS so I'd abandoned it. How does
> it fare for you compared to:
> select f1, f2 from fk where not exists (select 1 from pk where pk.f1=fk.f1
> and pk.f2=pk.f2) where f
Here is an email from the DBD:pg guys describing what _GNU_SOURCE does.
---
Jeroen Ruigrok/asmodai wrote:
> It's a glibc thing.
>
> Look at glibc's include/features.h:
>
> _GNU_SOURCE All of the above, plus GNU ex
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Well, we haven't even *got* a proposed patch yet, but yeah we should
> >> tread carefully.
>
> > OK. What releases had this slow restore problem?
>
> We introduced it in 7.3 --- before that, FKs were simply dump
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Let's have multiple people eyeball the patch and give it an OK and we
> > can add it for 7.4 if people want it.
>
> Well, we haven't even *got* a proposed patch yet, but yeah we should
> tread carefully. I do think it'd be okay to ap
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Now for something completely different:
> The postmaster executable shows --help display perfectly localized.
> However I just noted that postgres --help output (the standalone
> backend) does not; is it not i18n'ed, or is some sort of missetup?
postgr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jeroen Ruigrok/asmodai wrote:
>> "The crypt_r function is a GNU extension."
> BSD/OS doesn't have crypt_r(), and crypt() manual page says:
> The crypt() function may not be safely called concurrently from multiple
> threads, e.g., the interfac
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Let's have multiple people eyeball the patch and give it an OK and we
> can add it for 7.4 if people want it.
Well, we haven't even *got* a proposed patch yet, but yeah we should
tread carefully. I do think it'd be okay to apply a patch if we can
come u
On Sun, Sep 28, 2003 at 03:36:50PM -0400, Alvaro Herrera wrote:
> Now for something completely different:
Oh, there's another thing about the --help-config option. This option
includes an, er, option to display the items that belong to a given
group. So you could say
/tmp/pgsql-es/bin/postgres
> > Actually, all that's really necessary is the ability to call a stored
> > procedure when some event occurs. The stored procedure can take it from
> > there, and since it can be written in C it can do anything the postgres
> > user can do (for good or for ill, of course).
>
> But the postmaste
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, we haven't even *got* a proposed patch yet, but yeah we should
>> tread carefully.
> OK. What releases had this slow restore problem?
We introduced it in 7.3 --- before that, FKs were simply dumped as
"create trigger" commands,
On Sun, 28 Sep 2003, Bruce Momjian wrote:
> Stephan Szabo wrote:
> > Hmm, my initial testing showed that it really was a little slower
> > than a more complicated one with NOT EXISTS so I'd abandoned it. How does
> > it fare for you compared to:
> > select f1, f2 from fk where not exists (select
Bruce Momjian wrote:
> Kevin Brown wrote:
> > Actually, all that's really necessary is the ability to call a stored
> > procedure when some event occurs. The stored procedure can take it from
> > there, and since it can be written in C it can do anything the postgres
> > user can do (for good or f
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Sat, 27 Sep 2003, Tom Lane wrote:
>> I thought of what seems to be a better design for the check query: use
>> a LEFT JOIN and check for NULL in the righthand joined column.
> Hmm, my initial testing showed that it really was a little slower
> than a
On Sat, Sep 27, 2003 at 08:18:07PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > > What about creating a separate filenode anyway and renaming the files
> > > afterwards? It would not be an atomic operation anyway, but it would be
> > > better than the current setup IMHO.
> >
> > I think it w
Jeroen Ruigrok/asmodai wrote:
> -On [20030928 17:52], Tom Lane ([EMAIL PROTECTED]) wrote:
> >Hm. So is crypt_r() a GNU extension? I would've thought it was
> >specified by some standard or other. Perhaps the real issue here
> >is that /usr/include/crypt.h is usin
-On [20030928 17:52], Tom Lane ([EMAIL PROTECTED]) wrote:
>Hm. So is crypt_r() a GNU extension? I would've thought it was
>specified by some standard or other. Perhaps the real issue here
>is that /usr/include/crypt.h is using the wrong control symbol.
>At least in RHL 8.0, i
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> if count(*) = 0 from Room where roomno = new.roomno then
>> raise exception ''Room % does not exist'', new.roomno;
>> end if;
>>
>> Is this really intended to be a feature?
> I have to admit it was less an intention than more a side effec
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> _GNU_SOURCE All of the above, plus GNU extensions.
>>
>> Which means it enables all this:
>>
>> __STRICT_ANSI__, _ISOC99_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE,
>> _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, _LARGEFILE_SOURCE,
>> _LARGEFILE64_SOURCE
On Sunday 28 September 2003 11:53, mlg7 wrote:
> >On Saturday 27 September 2003 19:46, Peter Eisentraut wrote:
> >> mlg7 writes:
> >> > Is there a centralized list of pgsql PL's ?
> >>
> >> I'm not aware of one.
> >
> >http://techdocs.postgresql.org/guides/PLLanguages
> >
> >Josh posted it on advoc
51 matches
Mail list logo
