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
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
-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 Berkeley
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
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 exactly the
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 many
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
prepared plans
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 free
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
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
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'm not
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 a few
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 a
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]
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, this is
-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
Be
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
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
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. For
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 will
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 parent
27 matches
Mail list logo
