>From src/backend/tcop/postgres.c:
appendStringInfo(&str,
"!\t%ld/%ld [%ld/%ld] filesystem blocks in/out\n",
r.ru_inblock - Save_r.ru_inblock,
/* they only drink coffee at dec */
r.ru_oublock - Save_r.ru_oublock,
Tom Lane wrote:
You could make a
good case that we just ought to save query text and start from there in
any replanning; it'd be the most compact representation, the easiest to
copy around, and the least likely to break.
What happens if (for example) DateStyle changes between the two parses?
(not
Hi all,
In the OLE DB code there is code for parsing timestamps received from
the server. This code behaves erratically. Upon further examination, I
found the following piece of code in Postgresql's "timestamp2tm":
#ifdef HAVE_INT64_TIMESTAMP
dt -= CTimeZone * INT64CONST(100);
#else
Oliver Jowett wrote:
What happens if (for example) DateStyle changes between the two parses?
From my original email:
This is the common case of a more general problem: a query plan depends
on various parts of the environment at plan-creation time. That
environment includes the definitions of datab
Hi all,
Version 1.0.0.18 of OLE DB has just been uploaded to gborg. This is a
major upgrade than the previous versions, with most types now handled
(the #1 complaint about OLE DB thus far). As far as my understanding
goes, this version solves almost all of the problems that surfaced with
OLE DB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> We can't, because we can't revoke Berkeley's copyright. But in
> practice there's hardly any difference anyway.
Just out of curiosity, are the docs covered by the Berkeley copyright?
I know the code originally came from there, but did our current
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> > We can't, because we can't revoke Berkeley's copyright. But in
> > practice there's hardly any difference anyway.
>
> Just out of curiosity, are the docs covered by the B
i am trying to find that which file/function is
actually printing the QueryResults from
Executor..Please help
Thanks
Zahid
__
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
---(end of broadcast)--
> On Thu, 2005-03-17 at 13:36 -0500, Merlin Moncure wrote:
> > However, I still maintain that views are the perfect security
mechanism
> > for system catalogs. Imagine that all the system catalogs were all
> > views, and could be redefined or even dropped by the dba. They
would
> > present exactl
Michael Fuhr <[EMAIL PROTECTED]> writes:
> From src/backend/tcop/postgres.c:
> /* they only drink coffee at dec */
I never did figure out what that meant. Anyone know?
> Been there as far back as CVS goes. Will I find other goodies by
> poking around? :-)
There's a few jokes ... not that m
Neil Conway <[EMAIL PROTECTED]> writes:
> Oliver Jowett wrote:
>> What happens if (for example) DateStyle changes between the two parses?
> I'm don't think recreating the plan from the query string changes this
> fundamentally -- the interaction between (for example) GUC variables and
> prepare
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> In other words, it seems that I, as a client, needs to guess whether
> postgres was compiled with or without "HAVE_INT64_TIMESTAMP".
No, you need to inquire of the value of the "integer_datetimes"
parameter. (At least as of 8.0, this is provided "for
Zahid Khan <[EMAIL PROTECTED]> writes:
> i am trying to find that which file/function is
> actually printing the QueryResults from
> Executor..Please help
printtup() in access/common/printtup.c
regards, tom lane
---(end of broadcast)--
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It seems your patches do not fix the case when the table is a
> temporary table...
Ah, should've thought to try that case too. Thanks, Tatsuo.
regards, tom lane
---(end of broadcast)--
Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane:
> It doesn't eliminate the need for initdb, because pg_conversion contains
> instances of the client-only encoding numbers. I think that clients
> know the client-only encoding numbers too, so I'm not sure we aren't
> stuck with a compatibility
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane:
>> It doesn't eliminate the need for initdb, because pg_conversion contains
>> instances of the client-only encoding numbers. I think that clients
>> know the client-only encoding numbers too, so I'
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > From src/backend/tcop/postgres.c:
> > /* they only drink coffee at dec */
>
> I never did figure out what that meant. Anyone know?
>
> > Been there as far back as CVS goes. Will I find other goodies by
> > poking around? :-)
>
On Fri, 18 Mar 2005, Tom Lane wrote:
Michael Fuhr <[EMAIL PROTECTED]> writes:
From src/backend/tcop/postgres.c:
/* they only drink coffee at dec */
I never did figure out what that meant. Anyone know?
Been there as far back as CVS goes. Will I find other goodies by
poking around? :-)
There's
From src/backend/tcop/postgres.c:
>> /* they only drink coffee at dec */
Tcop might be pronounced "tea-cop"
IOW, 'We are the tea police."
In order to be sure what it means, I think you would have to ask the
original author of the quote.
-Original Message-
From: [EMAIL PROTECTED]
[ma
Tom Lane wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
In other words, it seems that I, as a client, needs to guess whether
postgres was compiled with or without "HAVE_INT64_TIMESTAMP".
No, you need to inquire of the value of the "integer_datetimes"
parameter. (At least as of 8.0, th
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Marc G. Fournier
> Sent: 18 March 2005 15:57
> To: Tom Lane
> Cc: Michael Fuhr; [EMAIL PROTECTED];
> pgsql-hackers@postgresql.org
> Subject: Re: [pgsql-www] [HACKERS] "they only drink coffee at dec"
Hi,
Bernd and myself are working in updateable views, one thing we find is
that when we have something like:
create table foo (
col1 serial,
col2 text default 'default'
);
create view vfoo as select * from foo;
then we create the appropiate rules for allow INSERT /UPDATE /DELETE
Tom Lane wrote:
It is well defined, because we insist that the gram.y transformation not
depend on any changeable state.
That's my point -- whether we begin from the query string or the raw
parsetree shouldn't make a difference. By not well-defined, I meant that
if the user is changing GUC variab
I've brought this back on-list, probably best that way..?
Eric Parusel wrote:
Tom Lane wrote:
What it kinda looks like from here is that you suffered a "page tear":
the itemid pointers at the front of the page may be self-consistent, but
they don't quite match the state of the rest of the page. Fo
Neil Conway <[EMAIL PROTECTED]> writes:
> ... By not well-defined, I meant that
> if the user is changing GUC variables on the fly, they can't rely on
> their prepared query being planned under any particular datestyle (or
> search path, etc.), since they can't really predict when replanning wil
Jaime Casanova <[EMAIL PROTECTED]> writes:
> ... but if we do INSERT INTO vfoo(col2) values ('some_string) the rewriter
> cann resolv the value for col1. the reason is that views does not
> inherit the defaults of the parent table. That is the reason you add
> the ALTER TABLE ALTER COLUMN ADD/DROP
On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> > ... but if we do INSERT INTO vfoo(col2) values ('some_string) the
> rewriter
> > cann resolv the value for col1. the reason is that views does not
> > inherit the defaults of the
27 matches
Mail list logo
