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 wh
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 t
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
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 t
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,
a
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 be
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 act
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 CR
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 w
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
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
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 th
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 fi
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 chang
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 co
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 l
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.
Th
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
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:
> > > >>
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 i
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 ar
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?
> > >> >
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 statement
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
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 M
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 abo
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
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 ne
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
s
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 ever
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
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
> 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 unclea
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
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 wo
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 t
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
[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
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
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=''' || sr
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 || ;
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
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,
43 matches
Mail list logo
