"Alex Hunsaker" wrote:
> >> > What did you want done with this patch? It is unlikely we want to see
> >> > those counters by default, and we have had little demand for them.
> >>
> >> This was already rejected in connection with pg_stat_statements, no?
> >
> > You know, I thought we discussed i
On Thu, Jan 8, 2009 at 17:30, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > What did you want done with this patch? It is unlikely we want to see
>> > those counters by default, and we have had little demand for them.
>>
>> >> Here is a patch that adds "buffer pool statist
KaiGai, Tom, all,
Attached is an updated patch which fixes Markus' dependency issue,
handles the other issues mentioned by KaiGai and Tom, has some
additional regressions tests to make sure all of that works, and has
been cleaned up to the 80-col goal (where it seemed to work well and
ma
On Thu, Jan 8, 2009 at 11:34 PM, Stephen Frost wrote:
>
> Please let me know if you have comments.
a fast test seems to show that this documentation change is no longer
true ;) nice work!
--- 443,450
! Currently, PostgreSQL does not recognize
! column-level SELECT priv
Bruce Momjian writes:
> Tom Lane wrote:
>> Isn't this redundant given the existence of pglesslog?
> It does the same as pglesslog, but is simpler to use because it is
> automatic.
Which also means that everyone pays the performance penalty whether
they get any benefit or not. The point of the e
I updated patch set of SE-PostgreSQL and related stuff (r1398).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1398.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1398.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy
Did we address this?
---
Merlin Moncure wrote:
> On Thu, Nov 6, 2008 at 12:45 PM, Tom Lane wrote:
> > "Merlin Moncure" writes:
> >> IMO, the client only build should be fixed, so we can:
> >> *) put the makefile hack I pro
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> > I've thought about it some, and yes, that sounds reasonable. I'll try
> > and implement it tonight and test it out.
I've implemented this and it appears to work well.
> When we refer table-rowtype, analyzer handles its Var->varattno has
>
Bruce Momjian wrote:
> I am now warning that we have an unusually large number of open items
> that must be either completed or moved to the TODO list before 8.4 can
> be released.
More threads to remove:
* [BUGS] BUG #4553: HOLD cursors not materializing results fully
was fixed here:
rev
Bruce Momjian escribió:
>
> What did you want done with this patch? It is unlikely we want to see
> those counters by default, and we have had little demand for them.
If there are two people who need them bad enough to have written a patch
for them, this seems to say that there is a certain dema
Tom Lane wrote:
> Bruce Momjian writes:
> > The attached patch from Aidan Van Dyk zeros out the end of WAL files to
> > improve their compressibility. (The patch was originally sent to
> > 'general' which explains why it was lost until now.)
>
> Isn't this redundant given the existence of pglessl
Tom Lane wrote:
> Bruce Momjian writes:
> > What did you want done with this patch? It is unlikely we want to see
> > those counters by default, and we have had little demand for them.
>
> >> Here is a patch that adds "buffer pool statistics" to the explain analyze
> >> output revealing the numb
On Fri, 9 Jan 2009, Hannu Krosing wrote:
won't it still be easier/less intrusive on inline core functionality and
more flexible to just record end-of-valid-wal somewhere and then let the
compressor discard the invalid part when compressing and recreate it
with zeros on decompression ?
I though
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>>> I'm open to suggestions about how to handle this. My first thought
>>> would be- add an entry to the cols_sel list for the RTE that is special
>>> and indicates "any column", perhaps by using a '0' for the
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:
On Thu, 8 Jan 2009 13:51:44 -0500 (EST)
Greg Smith wrote:
A. Einstein was a really smart dude.
Which character in the above example would you escape.
"." is on the long list of characters to be escaped I sent out earlier.
The parser looks for al
On Fri, 2009-01-09 at 01:29 +0200, Hannu Krosing wrote:
> On Thu, 2009-01-08 at 18:02 -0500, Aidan Van Dyk wrote:
...
> > There's possible a few other ways to do it, such as zero the WAL on
> > recycling (but not fsyncing it), and hopefully most of the zero's get
> > trickled out by the OS before i
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm open to suggestions about how to handle this. My first thought
> > would be- add an entry to the cols_sel list for the RTE that is special
> > and indicates "any column", perhaps by using a '0' for the attrid, as is
> > done e
On Thu, 2009-01-08 at 18:02 -0500, Aidan Van Dyk wrote:
> * Bruce Momjian [090108 16:43]:
> >
> > The attached patch from Aidan Van Dyk zeros out the end of WAL files to
> > improve their compressibility. (The patch was originally sent to
> > 'general' which explains why it was lost until now.)
>
>>> Aidan Van Dyk 01/08/09 5:02 PM >>>
> *I* would really like this wal zero'ing...
pg_clearxlogtail (in pgfoundry) does exactly the same zeroing of the
tail as a filter. If you pipe through it on the way to gzip, there
is no increase in disk I/O over a straight gzip, and often an I/O
savings.
Andrew Dunstan writes:
> I have just noticed that we do not include a description of the values
> used in confupdtype and confdeltype for pg_constraint in the system
> catalog docs. Should that be remedied,
Sure, go for it. See also confmatchtype.
regards, tom lane
--
Bruce Momjian writes:
> What did you want done with this patch? It is unlikely we want to see
> those counters by default, and we have had little demand for them.
>> Here is a patch that adds "buffer pool statistics" to the explain analyze
>> output revealing the number of buffer pages hit at ea
* Bruce Momjian [090108 16:43]:
>
> The attached patch from Aidan Van Dyk zeros out the end of WAL files to
> improve their compressibility. (The patch was originally sent to
> 'general' which explains why it was lost until now.)
>
> Would someone please eyeball it?; it is useful for compressin
Bruce Momjian writes:
> The attached patch from Aidan Van Dyk zeros out the end of WAL files to
> improve their compressibility. (The patch was originally sent to
> 'general' which explains why it was lost until now.)
Isn't this redundant given the existence of pglesslog?
I have mentioned this as a side issue in another thread. I thought
that it would be useful to start a separate thread for this. Perhaps
this won't be so difficult to code and we can forget all about the ReST
discussion.
So, I guess psql should pass XML to the user's filter and simply dump
its ou
I have just noticed that we do not include a description of the values
used in confupdtype and confdeltype for pg_constraint in the system
catalog docs. Should that be remedied, or is there some reason?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
---
Vladimir Sitnikov wrote:
> Hi all,
>
> Here is a patch that adds "buffer pool sta
D'Arcy J.M. Cain wrote:
> The problem with escaping is that someone may want this output for
> non-ReST purposes. They may not be making themselves known now but if
> we find a need later it will be hard if not impossible to make it
> available in a logical way. I would suggest that if we want a
The attached patch from Aidan Van Dyk zeros out the end of WAL files to
improve their compressibility. (The patch was originally sent to
'general' which explains why it was lost until now.)
Would someone please eyeball it?; it is useful for compressing PITR
logs even if we find a better solution
On Thu, 8 Jan 2009 13:51:44 -0500 (EST)
Greg Smith wrote:
> A. Einstein was a really
> smart dude.
>
> Is parsed as two lines of text, while:
>
> A. Einstein was a really smart dude.
>
> Will be treated as a single-item list. That sort of ambiguity is quite a
Yes, this is an issue. I'm not
ITAGAKI Takahiro wrote:
Magnus Hagander wrote:
ITAGAKI Takahiro wrote:
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
Hmm. Is this actually cleaner than using the original method as
suggested? Because if I understand things right, that
Added to TODO:
Allow archive_mode to be changed without server restart?
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php
---
Simon Riggs wrote:
>
> Currently we enable archive_mode
On Thu, 8 Jan 2009 13:05:03 -0500 (EST)
Bruce Momjian wrote:
> So what would this show?
>
> \*escape* \*escape*
>
> Want to bet the second word it italics.
Not in the Python implementation anyway. By the way, if you want to
try something, http://www.druid.net/darcy/rest.py.
--
D'Arcy J
Simon Riggs writes:
> On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
>> When a backend dies with FATAL, it writes an abort record before exiting.
>>
>> (I was under the impression it doesn't until few minutes ago myself,
>> when I actually read the shutdown code :-))
> Not in all
Ryan Bradetich wrote:
> Bruce,
>
> Thanks for adding this to the TODO.
> I am planning on continuing to work on this patch after 8.4 releases.
> I know we are in feature freeze and I do not want to sidetrack the
> release process.
Great.
--
Bruce Momjian http://momjian.us
Enterpris
Added to TODO:
Allow the creation of "distinct" types
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php
---
Peter Eisentraut wrote:
> Here is an implementation of distinct types, known fr
Simon Riggs wrote:
On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
When a backend dies with FATAL, it writes an abort record before exiting.
(I was under the impression it doesn't until few minutes ago myself,
when I actually read the shutdown code :-))
Not in all cases; keep re
Stephen Frost writes:
> I'm open to suggestions about how to handle this. My first thought
> would be- add an entry to the cols_sel list for the RTE that is special
> and indicates "any column", perhaps by using a '0' for the attrid, as is
> done elsewhere. Then modify ExecCheckRTEPerms() to han
Bruce,
Thanks for adding this to the TODO.
I am planning on continuing to work on this patch after 8.4 releases.
I know we are in feature freeze and I do not want to sidetrack the
release process.
Thanks!
- Ryan
On Thu, Jan 8, 2009 at 8:41 AM, Bruce Momjian wrote:
>
> Added to TODO:
>
>
On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > * if FATAL errors occur, yet we have long running transactions then we
> > have no way of removing those entries from the recovery procs. Since we
> > have a fixed pool of recovery transactions we won't have anyw
Tom, et al,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> KaiGai Kohei writes:
> > ExecCheckRTEPerms() checks user's privileges on columns, when he does
> > not have required privileges on the table. When he has proper privileges
> > on all the appeared columns within the table, it is allowed.
> > But
On Wed, Jan 07, 2009 at 05:49:12PM -0500, Tom Lane wrote:
> > It would be easy if the compiler were to have an option to throw a
> > warning when it finds a non-static variable that doesn't have a
> > corresponding extern declaration.
>
> Yeah, I think this is hopeless (or at least not worth the c
Simon Riggs wrote:
If you want to do things a different way you need to say what you want
to do and what effects those changes will have.
I want to reduce the coupling between the primary and the master. The
less they need to communicate, the better. I want to get rid of slotid,
and as many
Simon Riggs wrote:
* if FATAL errors occur, yet we have long running transactions then we
have no way of removing those entries from the recovery procs. Since we
have a fixed pool of recovery transactions we won't have anywhere to
store that data. Snapshot sizes are fixed maximum with max_connect
On Thu, 2009-01-08 at 20:30 +0200, Heikki Linnakangas wrote:
> I've mentioned before that I don't like the slotid stuff. From an
> architectural point of view, we should try to keep the extra
> communication between primary and standby to a minimum, for the sake of
> robustness. The primary sh
On Thu, 2009-01-08 at 14:15 -0500, Michael Glaesemann wrote:
> On Jan 8, 2009, at 13:56 , Joshua D. Drake wrote:
>
> > There is interest in ReST for anyone doing a lot more than Python or
> > Trac. Although that area is certainly strong with it. It is quickly
> > becoming one of the more dominant
On Thu, 8 Jan 2009 14:15:26 -0500
Michael Glaesemann wrote:
> I think there may be confusion here betwixt ReST/RST and REST.
>
> REST: http://en.wikipedia.org/wiki/Representational_State_Transfer
> ReST/RST: http://en.wikipedia.org/wiki/ReStructuredText
Really? I don't think anyone in this conv
On Jan 8, 2009, at 13:56 , Joshua D. Drake wrote:
There is interest in ReST for anyone doing a lot more than Python or
Trac. Although that area is certainly strong with it. It is quickly
becoming one of the more dominant technologies in delivering web
services (now whether or not that is useful
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Do you want to send an updated patch for it, or do you want me to look
at it?
I would send a new patch to which I added a simple ISO style check for
locale names.
Attached is a new patch.
I added a simple ISO style locale name check.
Avoided codi
On Thu, 2009-01-08 at 20:30 +0200, Heikki Linnakangas wrote:
> I've mentioned before that I don't like the slotid stuff. From an
> architectural point of view, we should try to keep the extra
> communication between primary and standby to a minimum, for the sake of
> robustness. The primary sh
"Joshua D. Drake" writes:
> There is interest in ReST for anyone doing a lot more than Python or
> Trac. Although that area is certainly strong with it. It is quickly
> becoming one of the more dominant technologies in delivering web
> services (now whether or not that is useful here is another ar
Bah, sorry for the duplication!
David
On Jan 8, 2009, at 11:00 AM, David E. Wheeler wrote:
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
Best,
David
citext_faq.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
On Thu, 2009-01-08 at 13:44 -0500, Greg Smith wrote:
> On Thu, 8 Jan 2009, Tom Lane wrote:
>
> > Well, actually, I *still* don't see the value in being able to emit ReST
> > --- nobody except D'Arcy has stated an interest in the feature.
>
> I suggested interest in it and pointed out the popular
Greg Smith writes:
> After spending some time assembling a list of special characters, I had an
> ah-ha moment when I realized they are all listed in the "Sections" section
> as "section title adornment characters":
> ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
I'll give yo
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:
On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
Bruce Momjian wrote:
Right, so Tom says it isn't 100% ReST:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
Right but did you see the followup?
http://archives.postgresql.org/pgsql
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
Best,
David
citext_faq.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
On Thu, 8 Jan 2009, Tom Lane wrote:
Well, actually, I *still* don't see the value in being able to emit ReST
--- nobody except D'Arcy has stated an interest in the feature.
I suggested interest in it and pointed out the popularity of ReST for
anyone using Trac or Python, and Cedric Villemain
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:
Some people suggests that this is so close to rst that I should just use
it as if it were, and hand-edit the output for the rare cases where it
doesn't comply. I don't find this very compelling.
The cases are so rare that I can't remember what they
I wrote:
> I'd prefer not to have ExecPrepareExpr do it, though; that's supposed
> to be working from a read-only expression tree supplied by the caller.
> (The fix_opfuncids call in it is already pushing the bounds of that
> concept.)
> From a structural point of view the right thing would be to
Tom Lane wrote:
> Bruce Momjian writes:
> > Yes, I did, and now I see why you said there might be only a few broken
> > cases. But I did not see any documentation in the standard saying that
> > was OK:
> > http://docutils.sourceforge.net/docs/user/rst/quickref.html#escaping
>
> The example
Bruce Momjian writes:
> Yes, I did, and now I see why you said there might be only a few broken
> cases. But I did not see any documentation in the standard saying that
> was OK:
> http://docutils.sourceforge.net/docs/user/rst/quickref.html#escaping
The example on that page is just bizarre
***
PHP Quebec is proud to present the PHP Quebec Conference 2009.
***
When: From 4 to 6 March 2009
Where: Downtown Montreal at the Bonaventure Hilton Hotel, at 900 de la
Gauchetière West
What: For three days, PHP and databases expe
Tom Lane wrote:
> Alvaro Herrera writes:
> > People change their mind, or they forget the decision they took last
> > time and take the opposite one later. Tom said that he didn't see a
> > value in rst:
> > http://archives.postgresql.org/message-id/27079.1219365411%40sss.pgh.pa.us
>
> Well, act
"D'Arcy J.M. Cain" writes:
> On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
> Bruce Momjian wrote:
>> Right, so Tom says it isn't 100% ReST:
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
> Right but did you see the followup?
> http://archives.postgresql.org/pgsql-hackers/2008
D'Arcy J.M. Cain wrote:
> On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
> Bruce Momjian wrote:
> > Right, so Tom says it isn't 100% ReST:
> >
> > http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
>
> Right but did you see the followup?
>
> http://archives.postgresql.org/pgsql-hack
On Thu, 8 Jan 2009 12:08:06 -0500 (EST)
Bruce Momjian wrote:
> Right, so Tom says it isn't 100% ReST:
>
> http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php
Right but did you see the followup?
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01319.php
--
D'Arcy J.M
Alvaro Herrera writes:
> People change their mind, or they forget the decision they took last
> time and take the opposite one later. Tom said that he didn't see a
> value in rst:
> http://archives.postgresql.org/message-id/27079.1219365411%40sss.pgh.pa.us
Well, actually, I *still* don't see the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > D'Arcy J.M. Cain wrote:
>
> > > In fact I wrote it because I do want it for ReST. When I first
> > > proposed it that was my sell. I received pushback because it was for
> > > too specific a purpose so I stepped back and showed that it was simply
Sorry for the noise, I didn't mean to sent this to the mailing list..
(the context is that this bug was found by a test case in EnterpriseDB
JDBC buildfarm)
Heikki Linnakangas wrote:
Tom fixed this upstream, and I just merged with PostgreSQL CVS HEAD
again. The buildfarm crash should now be f
Bruce Momjian wrote:
> D'Arcy J.M. Cain wrote:
> > In fact I wrote it because I do want it for ReST. When I first
> > proposed it that was my sell. I received pushback because it was for
> > too specific a purpose so I stepped back and showed that it was simply
> > a logical extension that happe
Tom fixed this upstream, and I just merged with PostgreSQL CVS HEAD
again. The buildfarm crash should now be fixed.
Rushabh Lathia wrote:
Hi All,
While running test with bind varible getting segmentation fault. ( CVS Head
8.4)
For testcase, please find the crash.c (C test) and test.java ( JDB
C?dric Villemain wrote:
> Bruce Momjian a ?crit :
> > D'Arcy J.M. Cain wrote:
> >> On Thu, 8 Jan 2009 12:30:52 -0300
> >> Alvaro Herrera wrote:
> It is a great feature for people actually using ReST. However, the
> feature is really just a logical extension to the existing border
>
Added to TODO:
Reduce data row alignment requirements on some 64-bit systems
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php
---
Ryan Bradetich wrote:
> Hello all,
>
> Her
On Thu, 2009-01-08 at 11:38 +0200, Peter Eisentraut wrote:
> I have recently fixed the configure script to recognize Python 3.0. But
> note that building and running PL/Python with Python 3.0 does not
> actually work. It looks like several symbols have been removed or
> changed. It would be g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian a écrit :
> D'Arcy J.M. Cain wrote:
>> On Thu, 8 Jan 2009 12:30:52 -0300
>> Alvaro Herrera wrote:
It is a great feature for people actually using ReST. However, the
feature is really just a logical extension to the existing bo
D'Arcy J.M. Cain wrote:
> On Thu, 8 Jan 2009 12:30:52 -0300
> Alvaro Herrera wrote:
> > > It is a great feature for people actually using ReST. However, the
> > > feature is really just a logical extension to the existing border
> > > attribute.
> >
> > Frankly I don't understand your position.
Magnus, et al,
* Magnus Hagander (mag...@hagander.net) wrote:
> Looking at the open item about the new error message shown when Kerberos
> is compiled in, and not used:
> assword:
> FATAL: password authentication failed for user "mha"
> psql: pg_krb5_init: krb5_cc_get_principal: No credentials ca
On Thu, 8 Jan 2009 12:30:52 -0300
Alvaro Herrera wrote:
> > It is a great feature for people actually using ReST. However, the
> > feature is really just a logical extension to the existing border
> > attribute.
>
> Frankly I don't understand your position. You seem to be saying that
> you want
Added to TODO:
Add support for WITH RECURSIVE ... CYCLE
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php
---
Tom Lane wrote:
> I looked a bit at the SQL:2008 spec for a CYCLE clause for WITH
> RECUR
Magnus Hagander writes:
> The reason this is happening is that we are initializing Kerberos even
> if we're not going to use it. The reason for doing *this*, is that if
> kerberos is compiled in, we use it to find out if we should try a
> different username than the one logged in to the local syst
On Thu, Jan 08, 2009 at 02:39:52PM +0200, Peter Eisentraut wrote:
> David Fetter wrote:
>> +1 for adding recursion to GRANT/REVOKE :)
>
> This area is under SQL standard control, so we can't really invent our
> own behavior.
>
> Consider the following:
>
> CREATE TABLE persons (name, email);
> CR
Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user "mha"
psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found
FATAL: password authentication failed for user "mha"
The re
Bruce Momjian writes:
> Well, did anyone say they actually liked the new format,
> appearance-wise, or would use it independently of ReST --- I don't
> remember anyone, and we don't want to extend the output format unless
> there is user demand.
Yeah. If it's not really ReST-compliant then the o
D'Arcy J.M. Cain wrote:
> On Wed, 07 Jan 2009 18:12:58 -0500
> Tom Lane wrote:
> > I think what Bruce meant to say is that this patch doesn't produce
> > 100% spec-compliant ReST, and that almost-ReST doesn't seem like a
> > good feature.
>
> It is a great feature for people actually using ReST.
D'Arcy J.M. Cain wrote:
> On Wed, 07 Jan 2009 18:12:58 -0500
> Tom Lane wrote:
> > "D'Arcy J.M. Cain" writes:
> > > Bruce Momjian wrote:
> > >> As I remember, no actual patch was posted for this.
> >
> > > There was. I am attaching it again in case there were any changes
> > > to original file
On Wed, 07 Jan 2009 18:12:58 -0500
Tom Lane wrote:
> "D'Arcy J.M. Cain" writes:
> > Bruce Momjian wrote:
> >> As I remember, no actual patch was posted for this.
>
> > There was. I am attaching it again in case there were any changes
> > to original files in the meantime.
>
> I think what Bru
>>> I wrote:
Peter Eisentraut wrote:
>> Kevin Grittner wrote:
"is a natural consequence of the fact" --- There is nothing
natural about any of this. Why is it a consequence and how?
>>>
>>> How could you possibly get any of those phenomena if there are no
>>> concurrent transac
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> Then I noticed that the SQL standard requires parentheses, like
>>
>> TRUNCATE ONLY (a), b
>>
>> which is clearer.
> Hmm, if I want to truncate only both (or is that "both only"?), what do
> I have to do?
> TRUNCATE ONLY (a, b)
Yeah. To me
OK, Heikki still believe the behavior below is a bug. Can I get
feedback from anyone else on this? TODO item?
---
> Heikki Linnakangas wrote:
> > Sushant Sinha wrote:
> > > Patch #2. I think this is a straigt forward bug f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Eisentraut a écrit :
> While working on TRUNCATE with ONLY, I said to myself, hmm, when writing
>
> TRUNCATE ONLY a, b
>
> it might be a bit confusing whether the ONLY refers to a or both a and
> b. Then I noticed that the SQL standard require
"Hitoshi Harada" writes:
> 2009/1/8 Tom Lane :
>> You mean set_mark? It's just to save an extra calculation of the
>> absolute location of the fetched row. See leadlag_common for an
>> example use: we can truncate the tuplestore if the offset is constant.
> Yeah, I mean set_mark :P) I already c
While checking out Rushabh Lathia's recent report I noticed $subject.
This is inconsistent because PQexec() returns PGRES_EMPTY_QUERY.
Is it something we should fix, or leave well enough alone on backward
compatibility grounds?
The cause seems to be that the backend (correctly) returns a NoData
re
"Rushabh Lathia" writes:
> While running test with bind varible getting segmentation fault. ( CVS Head
> 8.4)
Fixed, thanks.
> Another fix would be to add check for parseTree into
> analyze_requires_snapshot().
This one seems the more bulletproof approach.
regards, to
Peter Eisentraut wrote:
> While working on TRUNCATE with ONLY, I said to myself, hmm, when writing
>
> TRUNCATE ONLY a, b
>
> it might be a bit confusing whether the ONLY refers to a or both a and
> b. Then I noticed that the SQL standard requires parentheses, like
>
> TRUNCATE ONLY (a), b
>
> w
2009/1/8 Tom Lane :
> "Hitoshi Harada" writes:
>> - Is WinGetFuncArgInPartition()'s argument mark_pos required? For the
>> newbies to window functions, it seems a bit confusing, but
>> WinSetMarkPos() looks enough for the purpose AFAIK.
>
> You mean set_mark? It's just to save an extra calculatio
While working on TRUNCATE with ONLY, I said to myself, hmm, when writing
TRUNCATE ONLY a, b
it might be a bit confusing whether the ONLY refers to a or both a and
b. Then I noticed that the SQL standard requires parentheses, like
TRUNCATE ONLY (a), b
which is clearer. While we support that
Tom Lane wrote:
+1 for making TRUNCATE and LOCK support ONLY.
Patch attached.
I don't care much about
ALTER TABLE SET SCHEMA, but perhaps there's a use-case for recursion
on that.
I have added this to the Todo list for later reconsideration.
Index: doc/src/sgml/ref/lock.sgml
==
"Hitoshi Harada" writes:
> - CREATE FUNCTION command accepts WINDOW keyword for non-c language
> like plpgsql. Don't we need to throw error?
No. CREATE FUNCTION has no business trying to keep track of which
PLs implement what. That case won't do anything useful right now,
but it might do someth
KaiGai Kohei writes:
> ExecCheckRTEPerms() checks user's privileges on columns, when he does
> not have required privileges on the table. When he has proper privileges
> on all the appeared columns within the table, it is allowed.
> But, when no columns are used on the table, it applies result of
David Fetter wrote:
+1 for adding recursion to GRANT/REVOKE :)
This area is under SQL standard control, so we can't really invent our
own behavior.
Consider the following:
CREATE TABLE persons (name, email);
CREATE TABLE employees (grade, salary) INHERITS (persons);
GRANT SELECT ON persons
1 - 100 of 107 matches
Mail list logo
