Bruce Momjian said:
>
> I was hoping to avoid platform-specific binaries. Once pg_ctl is done
> in C, it can start/stop the postmaster, but not individual backends.
> Can we add a flag to pg_ctl so it can send arbitrary signals to
> processed on Win32? That would be best, I think.
>
Ok, that mak
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Would you show an example of the invalid value this is trying to avoid?
Well, the way I discovered the problem was by sending a timestamp in
double format when the server was expecting one in int64 format. This
is when using the binary data method for
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Bruce Momjian ([EMAIL PROTECTED]) wrote:
>> Would you show an example of the invalid value this is trying to avoid?
> Well, the way I discovered the problem was by sending a timestamp in
> double format when the server was expecting one in int64 format
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> >> Would you show an example of the invalid value this is trying to avoid?
>
> > Well, the way I discovered the problem was by sending a timestamp in
> > double format
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > Would you show an example of the invalid value this is trying to avoid?
>
> Well, the way I discovered the problem was by sending a timestamp in
> double format when the server was expecting one i
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > > Would you show an example of the invalid value this is trying to avoid?
> >
> > Well, the way I discovered the problem was by sending a timestamp
Stephen Frost wrote:
> > So you are passing the data via binary COPY or a C function?
>
> Sorry I wasn't clear, it's using libpq and binary data using an 'insert'
> statement. The code looks something like this:
>
> PQexec(connection,"prepare addrow (timestamp) as insert into mytable
> values ($
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > I'll see about writing up a proper test case/schema. Looks like I'm
> > probably most of the way there at this point, really. ;)
>
> I wasn't aware you could throw binary values into the timestamp fields
> like that. I thought
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > Stephen Frost wrote:
> > > I'll see about writing up a proper test case/schema. Looks like I'm
> > > probably most of the way there at this point, really. ;)
> >
> > I wasn't aware you could thro
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Considering all the other things the database is doing, I can't imagine
> that would be a measurable improvement.
It makes it easier on my client program too which is listening to an
ethernet interface and trying to process all of the packets coming in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I wasn't aware you could throw binary values into the timestamp fields
> like that. I thought you needed to use a C string for the value.
This facility was added in 7.4 as part of the wire-protocol overhaul.
It's nothing directly to do with PREPARE; you
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I wasn't aware you could throw binary values into the timestamp fields
> > > like that. I thought you needed to use a C string for the value.
> >
> > This facility was added in 7.4 as
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I wasn't aware you could throw binary values into the timestamp fields
> > like that. I thought you needed to use a C string for the value.
>
> This facility was added in 7.4 as part of the wire-protocol overhaul.
> It's nothing dire
Stephen Frost <[EMAIL PROTECTED]> writes:
>> How many datatype have this issue?
> I don't think that many do.. A number of them already check incoming
> values where it's possible for them to not be valid.
In general we do check incoming binary values to ensure minimal
validity. I think when I
I wrote:
> In general we do check incoming binary values to ensure minimal
> validity. I think when I did timestamp_recv I was thinking it was
> just like int8 or float8 (respectively), in that any bit pattern is
> potentially legal; I had forgotten about the range restrictions.
> I haven't looke
After trying to do some custom dumping/restoring, and having to resort
to the awful trick of changing the trigger counts on the catalog (the
stuff pg_dump adds), decided to add a couple little variables to control
disabling constraints and triggers. Added them to guc.c so that they
show up in the S
Jorge Pereira <[EMAIL PROTECTED]> writes:
> ... decided to add a couple little variables to control
> disabling constraints and triggers.
I'm not of the opinion that we actually want any such thing, as it's a
blatant violation of the fundamental concept of data integrity. But in
any case not with
[ Will apply with adjustment, removing tablespaces.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
--
Tom Lane wrote:
Jorge Pereira <[EMAIL PROTECTED]> writes:
... decided to add a couple little variables to control disabling constraints and triggers.
I'm not of the opinion that we actually want any such thing, as it's a
blatant violation of the fundamental concept of data integrity.
I c
Yes, agreed. I think we decided that super-user-only could disable
trigger on a global basis. I prevent folks from mucking with the system
tables to do it.
---
Jorge Pereira wrote:
> Tom Lane wrote:
>
> >Jorge Pereira <[E
Yes, agreed. I think we decided that super-user-only could disable
trigger on a global basis. I prevent folks from mucking with the system
tables to do it.
It should be a per-table thing:
ALTER TABLE blah [ DISABLE | ENABLE ] [ALL | FOREIGN KEY ] TRIGGERS;
Chris
---(end of
Christopher Kings-Lynne wrote:
Yes, agreed. I think we decided that super-user-only could disable
trigger on a global basis. I prevent folks from mucking with the system
tables to do it.
It should be a per-table thing:
ALTER TABLE blah [ DISABLE | ENABLE ] [ALL | FOREIGN KEY ] TRIGGERS;
Doing it
Doing it with "alter table" seems to imply that the change is permanent
(eg, the table loses checking), whereas that is most certainly not what
is wanted. With a SET variable it lasts only for the session, and
doesn't have to be reset manually.
Ah, then in that case, how about adding to the exis
Hi
I want to download PostgreSQL How it is work?
valBG
After trying to do some custom dumping/restoring, and having to resort
to the awful trick of changing the trigger counts on the catalog (the
stuff pg_dump adds), decided to add a couple little variables to control
disabling constraints and triggers. Added them to guc.c so that they
show up in t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> It should be a per-table thing:
Exactly. I don't care whether you're superuser, you should not be able
to disable all triggers, and certainly any facility provided for this
purpose should not encourage you to do that instead of disabling just
26 matches
Mail list logo
