El 2/7/2016 20:33, "Euler Taveira" escribió:
>
> On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote:
> > The attached patch adds a new function "to_date_valid()" which will
> > validate the date and return an error if the input and output date do
> > not match. Tests included, documentation update
On Sat, Jul 2, 2016 at 3:17 PM, Robert Haas wrote:
> In the interest of clarity, I was not intending to say that there
> should be a regression test in the patch. I was intending to say that
> there should be a test case with the bug report. I'm not opposed to
> adding a regression test, and I l
On Sat, Jul 2, 2016 at 8:31 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> Em sábado, 2 de julho de 2016, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
>> On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote:
>>
>>>
>>> What I would prefer is something like t
On 7/2/16 6:32 PM, Michael Paquier wrote:
> On Sun, Jul 3, 2016 at 4:54 AM, Heikki Linnakangas wrote:
>
>> Michael, do you plan to submit a new version of this patch set for the next
>> commitfest? I'd like to get this committed early in the 9.7 release cycle,
>> so that we have time to work on al
On Sat, Jul 02, 2016 at 01:06:49PM -0400, David G. Johnston wrote:
> On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote:
>
> >
> > What I would prefer is something like this:
> >
> > CREATE TABLE foo(
> > f1 int NOT NULL COMMENT
> > 'the first field',
> > f2 int NOT NULL COMMENT
> >
On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote:
> The attached patch adds a new function "to_date_valid()" which will
> validate the date and return an error if the input and output date do
> not match. Tests included, documentation update as well.
>
Why don't you add a third parameter (say, v
On 2 July 2016 at 22:42, Bruce Momjian wrote:
>
> > I suspect, but cannot prove, that it is also safe to snapshot pg_xlog on
> a
> > separate filesystem if and only if you take the datadir snapshot before
> the
> > pg_xlog snapshot and you have wal_keep_segments high enough to ensure
> that WAL
>
Hello,
we have customers complaining that to_date() accepts invalid dates, and
returns a different date instead. This is a known issue:
http://sql-info.de/postgresql/notes/to_date-to_timestamp-gotchas.html
On the other hand this leads to wrong dates when loading dates into the
database, bec
Em sábado, 2 de julho de 2016, David G. Johnston
escreveu:
> On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja > wrote:
>
>>
>> What I would prefer is something like this:
>>
>> CREATE TABLE foo(
>> f1 int NOT NULL COMMENT
>> 'the first field',
>> f2 int NOT NULL COMMENT
>> 'the second
On Sun, Jul 3, 2016 at 4:54 AM, Heikki Linnakangas wrote:
> I took a quick look at the patch set now again, and except that it needs to
> have the multiple password verifier support refactored out, I think it's in
> a pretty good shape. I don't like the pg_upgrade changes and its support
> functio
On Fri, Jul 1, 2016 at 11:37 PM, Noah Misch wrote:
> I don't know, either. You read both Robert and me indicating that this bug
> fix will be better with a test, and nobody has said that a test-free fix is
> optimal. Here's your chance to obliterate that no-tests precedent.
In the interest of c
On Sat, Jul 2, 2016 at 3:20 PM, Kevin Grittner wrote:
> On Sat, Jul 2, 2016 at 1:29 PM, Noah Misch wrote:
>> On Fri, Jul 01, 2016 at 09:00:45AM -0500, Kevin Grittner wrote:
>
>>> I have been looking at several possible fixes, and weighing the
>>> pros and cons of each. I expect to post a patch l
So, the consensus so far seems to be: We don't want the support for
multiple password verifiers per user. At least not yet. Let's get SCRAM
working first, in a way that a user can only have SCRAM or an MD5 hash
stored in the database, not both. We can add support for multiple
verifiers per user
On Sat, Jul 2, 2016 at 1:29 PM, Noah Misch wrote:
> On Fri, Jul 01, 2016 at 09:00:45AM -0500, Kevin Grittner wrote:
>> I have been looking at several possible fixes, and weighing the
>> pros and cons of each. I expect to post a patch later today.
>
> This PostgreSQL 9.6 open item is past due for
Noah, all,
On Saturday, July 2, 2016, Noah Misch wrote:
> On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com )
> wrote:
> > > Do this:
> > >
> > > CREATE DATABASE test1;
> > > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> > >
On Fri, Jul 01, 2016 at 09:00:45AM -0500, Kevin Grittner wrote:
> On Fri, Jul 1, 2016 at 7:17 AM, Robert Haas wrote:
> > On Fri, Jul 1, 2016 at 2:48 AM, Andres Freund wrote:
> >>> This PostgreSQL 9.6 open item is past due for your status update. Kindly
> >>> send
> >>> a status update within 24
On Wed, Jun 29, 2016 at 11:50:17AM -0400, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > Do this:
> >
> > CREATE DATABASE test1;
> > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> >
> > Run pg_dumpall.
> >
> > In 9.5, this produces
> >
> > CREATE DATABA
> The problem is that, even if I set the reltuples and relpages of my choice, when I run the EXPLAIN clause for a query in which the 'newTable' is involved in (e.g. EXPLAIN SELECT * FROM newTable), I get the same
On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote:
>
> What I would prefer is something like this:
>
> CREATE TABLE foo(
> f1 int NOT NULL COMMENT
> 'the first field',
> f2 int NOT NULL COMMENT
> 'the second field',
> ...
> );
>
> which would ensure the comments are both next to t
Hi,
Currently we have CREATE TABLE statements in a git repository that look
roughly like this:
CREATE TABLE foo(
-- the first field
f1 int NOT NULL,
-- the second field
f2 int NOT NULL,
...
);
But the problem is that those comments don't obviously make it all the
way to the database,
Hi,
I fixed typos. and attached patch for this.
Thanks.
I only changed comments only in src/backend/utils/adt/tsvector_op.c
typos.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
Stefan Huehner writes:
> On Sat, Jul 02, 2016 at 11:35:52AM -0400, Tom Lane wrote:
>> Hmm, I can't reproduce this on HEAD, but it doesn't seem to look like
>> anything we've fixed post-beta2. Do you need to put any particular data
>> into the tables? Are you running with any nondefault configura
Re: Stefan Huehner 2016-07-02 <20160702160042.ga11...@huehner.biz>
> No data at all needed in table.
> In fact just create database + create 3 those objects is enough to reproduce
> it.
Confirmed here on Debian unstable amd64, beta2.
FEHLER: XX000: cache lookup failed for type 0
ORT: get_typle
On Sat, Jul 02, 2016 at 11:35:52AM -0400, Tom Lane wrote:
> Stefan Huehner writes:
> > re-testing our application Openbravo on 9.6beta2 i found the following
> > query failing to run with
> > ERROR: cache lookup failed for type 0
>
> Hmm, I can't reproduce this on HEAD, but it doesn't seem to lo
Stefan Huehner writes:
> re-testing our application Openbravo on 9.6beta2 i found the following query
> failing to run with
> ERROR: cache lookup failed for type 0
Hmm, I can't reproduce this on HEAD, but it doesn't seem to look like
anything we've fixed post-beta2. Do you need to put any parti
Hello,
re-testing our application Openbravo on 9.6beta2 i found the following query
failing to run with
ERROR: cache lookup failed for type 0
Tested on 9.6beta2
Specifically debian package version '9.6~beta2-1.pgdg+1' from
apt.postgresql.org
SELECT
SUM(C_ORDERLINE.LINENETAM
Well that's good to know. It was just curious that, in my case, I only saw
this in this particular function.
Anyway. I will consider to handle the memory the same way, if this is the
recommendation.
Many thanks.
/Closed
On Sat, Jul 2, 2016 at 4:45 PM, Tom Lane wrote:
> Dirk Rudolph writes:
>
Andreas Karlsson writes:
> Has any of the major PostgreSQL companies looked into sending members to
> the ISO committee? It would be nice if we could be represented.
Peter E. had observer status at one point, don't know if he still does.
regards, tom lane
--
Sent via
Peter Geoghegan writes:
> On Fri, Jul 1, 2016 at 8:37 PM, Noah Misch wrote:
>> PostgreSQL is open to moving features from zero test coverage to nonzero test
>> coverage. The last several releases have each done so. Does that
>> sufficiently clarify the policy landscape?
> Not quite, no. There
Dirk Rudolph writes:
> while implementing my own C function, I mentioned that some memory is not
> freed by the text_overlay function in varlena.c
By and large, that's intentional. SQL-called functions normally run
in short-lived memory contexts, so that any memory they don't bother to
pfree wi
On Sat, Jul 2, 2016 at 10:31:32PM +0800, Craig Ringer wrote:
> - Microsoft VSS is NOT safe, as it fails point 2. It is atomic only on a
> per-file level. You MUST use pg_start_backup() and pg_stop_backup() with WAL
> archiving or automated copy of the extra WAL if you use MS VSS. Most Windows
> ba
Victor Giannakouris - Salalidis writes:
> For some research purposes, I am trying to modify the existing statistics
> of some tables in the catalogs in order to change the execution plan,
> experiment with the EXPLAIN call etc.
> Concretely, what I'd like to do is to create a "fake" table with a
Hi all
I just noticed that the Pg docs on backups don't discuss what kind of
snapshots are safe for use without a pg_start_backup() and pg_stop_backup()
then copying the extra WAL.
I'd like to remedy that. My understanding is that it's safe to use a
filesystem or block device level snapshot witho
Hi,while implementing my own C function, I mentioned that some memory is not freed by the text_overlay function in varlena.cParticularly I mean the both substrings allocated by text_substring (according to the documentation of text_substring "The result is always a freshly palloc'd datum.") and one
Re: Andreas Karlsson 2016-07-02
> On 07/01/2016 11:41 AM, Christoph Berg wrote:
> > thanks for the patches. I applied all there patches on top of HEAD
> > (10c0558f). The server builds and passes "make check", pgcrypto still
> > needs work, though:
>
> Thanks, I had forgotten pgcrypto.
pgcrypto
Re: Tom Lane 2016-07-01 <26357.1467400...@sss.pgh.pa.us>
> I made some mostly-cosmetic changes to this and pushed it.
I confirm that Debian's out-of-tree python3 build works now when
invoked directly in the relevant plpython/hstore_plpython
subdirectories. Thanks!
Christoph
--
Sent via pgsql-h
On 7/2/16 12:40 AM, Peter Geoghegan wrote:
We should be more ambitious about adding test coverage to tuplesort.c.
IMHO, s/ to tuplesort.c//, at least for the buildfarm.
TAP tests don't run by default, so maybe that's the place to start
"going crazy" with adding more testing. Though I do think
Hello,
For some research purposes, I am trying to modify the existing statistics
of some tables in the catalogs in order to change the execution plan,
experiment with the EXPLAIN call etc.
Concretely, what I'd like to do is to create a "fake" table with a schema
of my choice (that's the easy part
38 matches
Mail list logo
