On Fri, 2011-11-04 at 13:48 +0100, Gabriele Bartolini wrote:
> This patch adds basic support of arrays in foreign keys, by allowing to
> define a referencing column as an array of elements having the same type
> as the referenced column in the referenced table.
> Every NOT NULL element in the ref
> "Torn disk sector"? Please, this is nonsense. Disks cannot write half a
> sector and then stop.
What I was intended to say is corruption due to hardware or some other
problem, not because when
Postgres is updating pg_control file. For example
http://cquirke.mvps.org/9x/baddata.htm.
I've always used -1-f - < file.sql. It is confusing that -1 doesn't warn you
when it wont work though.
Sent from my iPhone
On Jun 16, 2012, at 3:42 AM, Fabien COELHO wrote:
>
> Hello pgdev,
>
> (Second attempt)
>
> I've conducted a statistical study about PostgreSQL use in OSS. One of the
"Dickson S. Guedes" writes:
> What happens when Daylight saving time ends? Or it doesn't matter in
> this scenario?
Irrelevant, we're working in UTC-based timestamps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
2012/6/16 Tom Lane :
[... cut ...]
> (1) In backend_read_statsfile, make an initial attempt to read the stats
> file and then read GetCurrentTimestamp after that. If the local clock
> reading is less than the stats file's timestamp, we know that some sort
> of clock skew or glitch has happened, so
On Sat, Jun 16, 2012 at 7:15 PM, Jeff Janes wrote:
> On Thu, Jun 14, 2012 at 3:42 PM, Peter Eisentraut wrote:
>> Here is my first patch for the transforms feature. This is a mechanism
>> to adapt data types to procedural languages. The previous proposal was
>> here: http://archives.postgresql.o
On Thu, Jun 14, 2012 at 3:42 PM, Peter Eisentraut wrote:
> Here is my first patch for the transforms feature. This is a mechanism
> to adapt data types to procedural languages. The previous proposal was
> here: http://archives.postgresql.org/pgsql-hackers/2012-05/msg00728.php
When I apply this
I've had a vague feeling for awhile now that the occasional buildfarm
failures we see in the stats regression test (where it appears that the
stats collector fails to respond to requests for no good reason) might
be related to operating-system timekeeping glitches. Today there is
finally indisputa
2012/6/16 Tom Lane :
> I wrote:
>> Have the SQL committee simply failed to notice that in
>> whacking this text around they changed the meaning? Which behavior is
>> actually implemented by other RDBMSes?
>
> If anyone is up for actually trying this, here is a script to test the
> behavior in ques
On Thu, Jun 14, 2012 at 2:39 PM, Robert Haas wrote:
> On Wed, Jan 11, 2012 at 8:48 PM, Robert Haas wrote:
>> I've had cause, a few times this development cycle, to want to measure
>> the amount of spinning on each lwlock in the system. To that end,
>> I've found the attached patch useful. Note
On 18 March 2012 15:08, Tom Lane wrote:
> However, it occurred to me that we could pretty easily jury-rig
> something that would give us an idea about the actual benefit available
> here. To wit: make a C function that wraps strxfrm, basically
> strxfrm(text) returns bytea. Then compare the perf
Our foreign-key-related code uses MATCH_UNSPECIFIED to denote the
default foreign key match behavior. This corresponds to the wording
used in the SQL92 spec, for instance "If is not specified
or if FULL is specified, ...". But I always found it rather confusing;
it sounds like we don't know what
On 16 June 2012 21:18, Tom Lane wrote:
> Anybody have DB2, or something else that might be thought to be pretty
> close to spec-compliant?
>
I have an Oracle DB, but they're not exactly known for spec
compliance. In fact they dodge this entire issue by not supporting ON
UPDATE actions at all :-)
I wrote:
> Have the SQL committee simply failed to notice that in
> whacking this text around they changed the meaning? Which behavior is
> actually implemented by other RDBMSes?
If anyone is up for actually trying this, here is a script to test the
behavior in question:
create table pp (f1 int,
On 12-06-15 04:03 PM, Robert Haas wrote:
On Thu, Jun 14, 2012 at 4:13 PM, Andres Freund wrote:
I don't plan to throw in loads of conflict resolution smarts. The aim is to get
to the place where all the infrastructure is there so that a MM solution can
be built by basically plugging in a conflic
On Fri, Jun 15, 2012 at 3:53 PM, Simon Riggs wrote:
> On 10 June 2012 19:47, Joshua Berkus wrote:
>
>> So currently we have a major limitation in binary replication, where it is
>> not possible to "remaster" your system (that is, designate the most
>> caught-up standby as the new master) based
Hello Tom,
thanks for your answer.
So I would suggest the following todos:
1 - change the default verbosity to "warning".
The argument for defaulting to NOTICE is the same as it's always been:
that those messages are really intended for novices, and a pretty good
definition of a novice is so
While looking at Vik Reykja's pending patch to improve the FK triggers
by skipping processing when a NULL column didn't change, I started to
wonder whether that really had no user-visible semantic effect.
In particular, in ON UPDATE SET NULL/SET DEFAULT cases, it seemed like
this could change the s
There hasn't been any discussion of who will manage this CF that I've
heard. Since nature abhors a vacuum, I took some preliminary steps
to get it started, and will take the role if nobody objects.
If you want to review a particular patch, go ahead and claim it in
the CF application:
https://c
On 16 June 2012 18:04, Tom Lane wrote:
> Dean Rasheed writes:
>> BTW, I had no problems applying both the original patch and Chetan
>> Suttraway's version. The only difference between the patches seems to
>> be that the original is in context format, and Chetan Suttraway's is
>> in unified format
Dean Rasheed writes:
> BTW, I had no problems applying both the original patch and Chetan
> Suttraway's version. The only difference between the patches seems to
> be that the original is in context format, and Chetan Suttraway's is
> in unified format.
> Which format do hackers actually prefer?
On Sat, Jun 16, 2012 at 6:09 PM, Tom Lane wrote:
> I guess this raises the question of whether we ought to revert the
> row-callback patch entirely and support only this approach. IMO
> it is (barely) not too late to do that for 9.2, if we want to.
> If we don't want to, then this is just another
On Sat, Jun 16, 2012 at 11:15:30AM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane wrote:
> >> It's not obvious to me that we actually *need* anything except the
> >> ability to recognize that a null-encrypted SSL connection probably
> >> shouldn't
Magnus Hagander writes:
> This is copied from the old documentation. It used to say "It is not
> necessary to be concerned about the amount of time elapsed between
> pg_start_backup and the start of the actual backup, nor between the
> end of the backup and pg_stop_backup".
>
> And the whole idea
Fabien COELHO writes:
> [ errors in SQL scripts fed to psql are easily missed ]
> So I would suggest the following todos:
> 1 - change the default verbosity to "warning".
The argument for defaulting to NOTICE is the same as it's always been:
that those messages are really intended for novices, a
Magnus Hagander writes:
> On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane wrote:
>> It's not obvious to me that we actually *need* anything except the
>> ability to recognize that a null-encrypted SSL connection probably
>> shouldn't be treated as matching a hostssl line; which is not something
>> tha
Marko Kreen writes:
>> Now, looking at the problem with some perspective, the solution
>> is obvious: when in single-row mode, the PQgetResult() must return
>> proper PGresult for that single row. And everything else follows that.
>>
>> * PQgetRowData(): can be called instead PQgetResult() to ge
Demos:
https://github.com/markokr/libpq-rowproc-demos/blob/master/demo-onerow-sync.c
https://github.com/markokr/libpq-rowproc-demos/blob/master/demo-onerow-async.c
Few clarifications below.
On Fri, Jun 15, 2012 at 9:21 PM, Marko Kreen wrote:
> Now, looking at the problem with some perspective,
On Sat, Jun 16, 2012 at 01:10:31AM -0400, Noah Misch wrote:
> On Fri, Jun 15, 2012 at 10:45:16PM -0400, Bruce Momjian wrote:
> > I have updated the pgindent README to use
> > these Perl indent instructions:
> >
> > find . -name \*.pl -o -name \*.pm | xargs perltidy \
> > --backup-a
On 12 February 2012 02:06, Vik Reykja wrote:
> I decided to take a crack at the todo item created from the following post:
> http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
>
> The attached patch makes the desired changes in both code and function
> naming.
>
> It seemed quit
Hi Robert,
On Friday, June 15, 2012 10:03:38 PM Robert Haas wrote:
> On Thu, Jun 14, 2012 at 4:13 PM, Andres Freund
wrote:
> > I don't plan to throw in loads of conflict resolution smarts. The aim is
> > to get to the place where all the infrastructure is there so that a MM
> > solution can be b
On Sat, Jun 16, 2012 at 2:52 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Basically, I'd like to combine a recursive and a non-recursive CTE in
>> the same query.
>
> Just mark them all as recursive. There's no harm in marking a CTE as
> recursive when it isn't really.
Hah. I could've sworn
Hi hackers,
I found that lower case is less than upper case when the db is created
with utf8.
I tried below
locale en_US.utf8 'A'<'a' false
locale ja_JP.utf8 'A'<'a' true
locale zh_CN.utf8 'A'<'a' false
Under Windows
locale Chinese_China 'A'<'a' f
Hello pgdev,
(Second attempt)
I've conducted a statistical study about PostgreSQL use in OSS. One of the
result is that quite a few projects have errors in their SQL setup scripts
which lead to some statements to be ignored, typically somme ADD
CONSTRAINTS which do not change the database sc
34 matches
Mail list logo
