Ron Mayer napsal(a):
Tom Lane wrote:
Another issue is that it might not be possible to update a page for
lack of space. Are we prepared to assume that there will never be a
transformation we need to apply that makes the data bigger? In such a
situation an in-place update might be impossible,
Hello,
Postgres 8.4 has pg_stat_user_functions view to track number of calls of
stored functions and time spent in them. Then, I'm thinking a sql statement
version of similar view -- pg_stat_statements.
Prepared statements and statements using extended protocol are grouped
by their sql strings
pgsql-hackers:
The following is Oracle's PL/SQL
if resTypeTableName is null
then
queryStr := 'select IntIID, Path FROM aaResourceData' || ' where
ResType=''' || srcType || ''' and ResID=''' || srcID || ;
billy schrieb:
pgsql-hackers:
The following is Oracle's PL/SQL
if resTypeTableName is null
then
queryStr := 'select IntIID, Path FROM aaResourceData' || ' where
ResType=''' || srcType || ''' and ResID=''' || srcID ||
Bruce Momjian napsal(a):
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
4) Implementation
The main point of implementation is to have several version of
PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct
structure will be handled in special branch (see examples).
(this
[Sorry, just noticed that I didn't answer this email. ]
On Wed, Jun 04, 2008 at 05:06:41PM +0100, Mike Aubury wrote:
It might depend on the tokens..
Are =, ++ etc single tokens ?
...
Wouldn't it work to just always insert a space between tokens, no matter
whether there was one
I took a quick look at this - would it be ok to add some small amounts
of 'markup' to the gram.y ?
eg :
/* ECPGCOPYON */
/* ECPGCOPYOFF */
/* ECPGMODE=NOSPACE */
...
/* ECPGMODE=USESPACE */
etc ?
On Friday 13 June 2008 10:47:55 Michael Meskes wrote:
[Sorry, just noticed that I
Tom Lane napsal(a):
Reflecting on this thread:
http://archives.postgresql.org/pgsql-general/2008-06/msg00344.php
it strikes me that the elog messages in tuptoaster.c would be
significantly more useful if they gave the name of the toast table
containing the problem, which is readily available at
On Jun 12, 2008, at 12:25 PM, Bruce Momjian wrote:
Dickson S. Guedes wrote:
Hi all,
There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.
I'd like to work on this feature, if nobody is working too and no
objection exists.
Please do --- I know of no one
Mike Aubury [EMAIL PROTECTED] writes:
I took a quick look at this - would it be ok to add some small amounts
of 'markup' to the gram.y ?
eg :
/* ECPGCOPYON */
/* ECPGCOPYOFF */
/* ECPGMODE=NOSPACE */
...
/* ECPGMODE=USESPACE */
We're almost certainly going to need some kluges of
We're almost certainly going to need some kluges of that sort, so as
long as they're not all over the place I won't object.
But ... I've seen no evidence that those specific examples are needed.
Why wouldn't we copy all the backend rules? And based on Michael's last
comment it's unclear
Here is the SSL patch we discussed previously for 8.3.1.
sslconfig.patch.8.3.1
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Mike Aubury wrote:
Theres also another thing that needs to be decided, which is if the generated
ecpg grammer should be developer generated (ie. Michael Meskes runs a script
and commits the output), or should be generated for each and every source
based installation. I personally would
Alvaro Herrera [EMAIL PROTECTED] writes:
Mike Aubury wrote:
Theres also another thing that needs to be decided, which is if the
generated
ecpg grammer should be developer generated (ie. Michael Meskes runs a script
and commits the output), or should be generated for each and every source
The same as happens at the moment - nothing...
The grammer for the ecpg needs to be re-generated when the grammer in the main
parser is changed - whether its a manual or (mostly) automatic task is
largely irrelevant.
The only downside is that if its not regenerated then the change to gram.y
Mike Aubury [EMAIL PROTECTED] writes:
I was thinking about the copy on/copy off for more the header info (before
the %%) - so we can have a really dumb script that just gets told what blocks
to copy - and what to ignore..
I think you'll find that doesn't work very well; the script will need
Hi,
in 8.3.3 Documentation / F.34.Xml2 the Deprecation notice claims:
..the core server now covers XML syntax checking and XPath queries,
which is what Xml2 does, and more.
I can't get boolean values out from function xpath. I think there is a
missing implementation of xpath syntax.
Try for
Mike Aubury [EMAIL PROTECTED] writes:
What happens when a non-Michael developer changes the original gram.y?
The same as happens at the moment - nothing...
Wrong answer. The entire point of this work is to get rid of manual
work in updating the ecpg grammar when the main changes. The above
On Fri, Jun 13, 2008 at 02:57:54PM +0100, Mike Aubury wrote:
based installation. I personally would stongly favour the script being a tool
for ecpg tool developers and not used as part of a normal installation.
Why?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at
On Fri, Jun 13, 2008 at 10:39:48AM -0400, Alvaro Herrera wrote:
What happens when a non-Michael developer changes the original gram.y?
Is he expected to run the script before committing too? That sounds
brittle to me.
The situation used to be that this only caused ecpg to be out-of-sync.
No
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Postgres 8.4 has pg_stat_user_functions view to track number of calls of
stored functions and time spent in them. Then, I'm thinking a sql statement
version of similar view -- pg_stat_statements.
We don't have any system-wide names for statements, so
On Wednesday 11 June 2008 16:54:23 Bruce Momjian wrote:
Dave Page wrote:
On Wed, Jun 11, 2008 at 6:56 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED]
wrote:
pg_ctl -D data check?
I would +1 that.
Andrew Dunstan [EMAIL PROTECTED] writes:
Robert Treat wrote:
This conversation is beginning to suggest to me that client_encoding
shouldn't be listed in postgresql.conf at all.
Yeah, that sure seems better than what we currently have.
I should have thought there was a good argument for
Zdenek Kotala [EMAIL PROTECTED] writes:
It does not solve problems for example with TOAST tables. If chunks does not
fit
on a new page layout one of the chunk tuple have to be moved to free page. It
means you get a lot of pages with ~2kB of free unused space. And if max chunk
size is
Robert Treat wrote:
On Wednesday 11 June 2008 16:54:23 Bruce Momjian wrote:
Dave Page wrote:
On Wed, Jun 11, 2008 at 6:56 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED]
wrote:
pg_ctl -D data check?
James William Pye [EMAIL PROTECTED] writes:
On Jun 12, 2008, at 4:45 PM, Tom Lane wrote:
Huh? I don't see why... you might have such a limitation in a
particular driver, but not in the protocol.
Oh? I know when you bind a prepared statement you have the ability
state the formats of each
Bruce Momjian wrote:
Dickson S. Guedes wrote:
Hi all,
There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.
I'd like to work on this feature, if nobody is working too and no
objection exists.
Please do --- I know of no one working on that.
On Jun 12, 2008, at 17:55, Greg Sabino Mullane wrote:
Glad to hear that, although I think this is only in HEAD, not
backpatched,
right? Well at any rate, I withdraw my strong support for 100 and
join in
the quest for a good number. The anything but 10 campaign
I vote for 11. That's one
ITAGAKI Takahiro wrote:
Hello,
Postgres 8.4 has pg_stat_user_functions view to track number of calls of
stored functions and time spent in them. Then, I'm thinking a sql statement
version of similar view -- pg_stat_statements.
I can see how this would be useful, but I can also see that it
On Fri, 2008-06-13 at 17:33 +0900, ITAGAKI Takahiro wrote:
We can write sql statements in server logs and gather them using some
tools (pgfouine and pqa) even now, but statement logging has
unignorable overhead.
I would prefer to look at ways to reduce the current overhead rather
than change
On Fri, Jun 13, 2008 at 12:47:22PM -0400, Andrew Dunstan wrote:
The reason it wasn't done years ago was that there was disagreement on the
way it should work. And the TODO actually lists several alternatives:
Host name lookup could occur when the postmaster reads the
pg_hba.conf file,
Andrew Dunstan [EMAIL PROTECTED] writes:
The reason it wasn't done years ago was that there was disagreement on
the way it should work. And the TODO actually lists several alternatives:
IIRC, the major reason there was disagreement was the prospect of
unacceptable performance from any of the
On Fri, 2008-06-13 at 13:26 -0400, Andrew Sullivan wrote:
On Fri, Jun 13, 2008 at 12:47:22PM -0400, Andrew Dunstan wrote:
The reason it wasn't done years ago was that there was disagreement on the
way it should work. And the TODO actually lists several alternatives:
Host name lookup
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-06-13 at 17:33 +0900, ITAGAKI Takahiro wrote:
We can write sql statements in server logs and gather them using some
tools (pgfouine and pqa) even now, but statement logging has
unignorable overhead.
I would prefer to look at ways to reduce
On Fri, Jun 13, 2008 at 4:30 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The reason it wasn't done years ago was that there was disagreement on
the way it should work. And the TODO actually lists several alternatives:
IIRC, the major reason there was
On Wed, 2008-06-04 at 16:33 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We have
* relhasindex (bool) set by CREATE INDEX but not unset by DROP INDEX
* relhasrules (bool)
* reltriggers (int2) set by CREATE and DROP, since its an integer
Right.
If CREATE INDEX can
Andrew Sullivan wrote:
This is because DNS RRs have a TTL on them, so looking up the host at
any moment other than when you're actually doing the authentication is
prone to error.
Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of
On Jun 13, 2008, at 9:24 AM, Tom Lane wrote:
You'd do it while Binding a FETCH command.
Indeed, that is true. It seems quite unfortunate that drivers
have to jump through such hoops to provide a convenient
programmer's interface to held and/or scrollable cursors; bearing in
mind all that has
Alvaro Herrera [EMAIL PROTECTED] writes:
Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of actually checking you need only get
a new answer for those that expired.
This is not behavior we'd want to put into the postmaster, though,
and
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of actually checking you need only get
a new answer for those that expired.
This is not behavior we'd want to put into
On Fri, 13 Jun 2008, James William Pye wrote:
My thoughts for creating a HOLD and/or SCROLL cursor on Bind would be to
add YA GUC stating the cursor options for Bind cursors. Something along
the lines of default_bind_options=HOLD,SCROLL.
2. I'm the only one asking/looking for it. (I'm so
On Jun 13, 2008, at 4:40 PM, Kris Jurka wrote:
The JDBC driver would also like this ability, but a GUC is a pretty
ugly hack.
I completely agree that it is an ugly hack. :)
Also, since you still have to go to the SQL level to issue the MOVE
or FETCH BACKWARD, you're still not all the way
On Fri, Jun 13, 2008 at 08:51:19PM +0100, Simon Riggs wrote:
The best of both ideas would be to have an option inside pg_hab.conf to
indicate when lookup occurs. Some parts of a network are static, others
are not, so a global option would not be useful.
We would point and laugh at people who
43 matches
Mail list logo
