On Fri, Jun 13, 2014 at 11:32 AM, Tom Lane wrote:
> David G Johnston writes:
> > Tom Lane-2 wrote
> >> At the very least I think we should stay away from this syntax until
> >> the SQL committee understand it better than they evidently do today.
> >> I don't want to implement it and then get cau
On Fri, Jul 11, 2014 at 12:12 PM, Michael Banck wrote:
> On Fri, Jul 11, 2014 at 11:07:21AM -0400, Tom Lane wrote:
> > David G Johnston writes:
> > > Benedikt Grundmann wrote
> > >> That is it possible to tell the planner that index is off limits
> > >> i.e.
> > >> don't ever generate a plan usi
On Fri, Aug 1, 2014 at 8:15 PM, Gavin Flower
wrote:
> On 02/08/14 12:32, David G Johnston wrote:
>
>>
>> Any supporting arguments for 1-10 = 1st decade other than technical
>> perfection? I guess if you use data around and before 1AD you care about
>> this more, and rightly so, but given sound a
On Thu, Aug 7, 2014 at 5:53 PM, Tom Lane wrote:
> David G Johnston writes:
> > Tom Lane-2 wrote
> >> Surely that was meant to read "invalid number OF arguments". The
> errhint
> >> is only charitably described as English, as well. I'd suggest something
> >> like "Arguments of json_build_object
Alvaro Herrera-9 wrote
> Björn Harrtell wrote:
>> I've written a variant of regexp_matches called regexp_matches_positions
>> which instead of returning matching substrings will return matching
>> positions. I found use of this when processing OCR scanned text and
>> wanted
>> to prioritize matches
Erik Rijkers wrote
> On Wed, January 29, 2014 05:16, David Johnston wrote:
>>
>> How does this resolve in the patch?
>>
>> SELECT regexp_matches('abcabc','((a)(b)(c))','g');
>>
>
> With the patch:
>
> testdb=# SELECT reg
Sawada Masahiko wrote
> Hi all,
>
> Attaching patch provides new value 'dml' for log_statement.
> Currently, The server logs modification statements AND data definition
> statements if log_statement is set 'mod'.
> So we need to set the 'all' value for log_statement and remove
> unnecessary infor
salah jubeh wrote
> Hello,
>
> I find default values confusing when a function is overloaded, below is an
> example.
>
>
> CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1,
> C INT DEFAULT 1) RETURNS INT AS
> $$
> BEGIN
> RETURN a+b+c;
> END;
> $$
> LANG
Leon Smith wrote
> Hi, I'm the maintainer and a primary author of a postgresql client
> library
> for Haskell, called postgresql-simple, and I recently investigated
> improving support for VALUES expressions in this library. As a result,
> I'd
> like to suggest two changes to postgresql:
>
> 1
Ali Piroozi wrote
> Hi
> Which equivalence rule from those are listed in
> email's attachment are implemented in postgresql?
> where are them?
What do you mean by "where"?
The various JOINS and UNION/INTERSECT/DIFFERENCE are all defined
capabilities.
SQL is not purely relational in nature so som
mohsencs wrote
> I want use CREATE TYPE to create one type similar to char.
> I want to when I create type, then my type behave similar to char:
>
> CREATE TABLE test (oneChar char);
>
> when I want insert one column with length>1 to it, so it gets this error:
> ERROR: value too long for type ch
Josh Berkus wrote
> Hackers,
>
> In the 9.3.3 updates, we added three new GUCs to control multixact
> freezing. This was an unprecented move in my memory -- I can't recall
> ever adding a GUC to a minor release which wasn't backwards
> compatibility for a security fix. This was a mistake.
It pr
Andrew Dunstan wrote
> On 03/11/2014 11:50 PM, Jaime Casanova wrote:
>> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane <
> tgl@.pa
> > wrote:
>>> But not sure how to define a unique
>>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>>> (joe, 0).
>>>
>> and why you want that res
Tom Lane-2 wrote
> Unfortunately, while testing it I noticed that there's a potentially
> fatal backwards-compatibility problem, namely that the "COPY n" status
> gets printed on stdout, which is the same place that COPY OUT data is
> going. While this isn't such a big problem for interactive use,
Instead of simply expanding the section on sub-queries, which may still be
worthwhile, it seems that we have effectively introduced a new "kind" of
query - namely one that mixes both query DDL and update DDL into a kind of
hybrid query. An entire section describing the means to implement these
que
Tom Lane-2 wrote
> Pavel Stehule <
> pavel.stehule@
> > writes:
>> I was one who sent a bug report - this error is not too dangerous, but it
>> is hidden, and difficult to find, if you don't know what can be happen.
>> Same as bug with plpgsql and SQL identifier collisions. If you
>> understand,
Andres Freund-3 wrote
> On 2013-08-30 06:34:47 -0700, David Johnston wrote:
>> Tom Lane-2 wrote
>> >> I was one who sent a bug report - this error is not too dangerous, but
>> it
>> >> is hidden, and difficult to find, if you don't know what can be
>&
Jeff Davis-8 wrote
> Is there any semantic difference between marking a constraint as
> DISABLED and simply dropping it? Or does it just make it easier to
> re-add it later?
I cannot answer the question but if there is none then the main concern I'd
have is capturing "meta-information" about WHY s
Tom Lane-2 wrote
> Michael Nolan <
> htfoot@
> > writes:
>> This is 9.3 RC1 on a Fedora 7 system. Why does \l report the encoding
>> as SQL_ASCII and \set report it as UTF8?
>
> psql sets client_encoding based on its environment (LANG or related
> variables). That's been true for some time ---
Tatsuo Ishii-4 wrote
>
> From these statements, I would think #4 will fail in the following
> sequence of commands because #3 closes transaction and it destroys
> unnamed portal: 1)Parse/Bind creates unnamed portal,
> 2)Parse/Bind/Execute creates named portal and executes, 3)Send Sync
> message (b
Continuing my "novice interpretation" from before...
Tatsuo Ishii-4 wrote
> It would be nice if something like "unnamed portal will be destroyed
> by a Sync message if you are in an explicit transaction" is in our
> manual.
I do not believe this to be true from what I've scanned. Inside an
"imp
Noah Misch-2 wrote
> The errfinish() pertaining to that WARNING issues CHECK_FOR_INTERRUPTS(),
> and
> the query cancel pending since before the SIGQUIT arrived then takes
> effect.
> This is less bad on 9.4, because the postmaster will SIGKILL the backend
> after
> 5s. On older releases, the back
Noah Misch-2 wrote
>> > I'm thinking to preserve postmaster.pid at immediate shutdown in all
>> released
>> > versions, but I'm less sure about back-patching a change to make
>> > PGSharedMemoryCreate() pickier. On the one hand, allowing startup to
>> proceed
>> > with backends still active in the
Ants Aasma-2 wrote
>> So, has anyone compiled checksum vectorized on OS X? Are there any
>> performance data that would indicate whether or not I should worry with
>> this in the first place?
>
> Even without vectorization the worst case performance hit is about
> 20%. This is for a workload that
Misa Simic wrote
> I guess that rule can be achieved with triigers on TableA and TableC - but
> the same is true for FK (and FK constraint is more effective then trigger
> -
> that is why I wonder would it be useful/achievable to create that kind of
> constraint)
>
> Thoughts, ideas?
You create a
Misa Simic wrote
> Hi hackers,
>
> I just wonder how hard would be to implement something like "Not In FK
> Constraint" or opposite to FK...
A more useful couple next sentences would be along the lines of:
I have this problemI've approached it by doingbut it seems that an
actual database
Amit Kapila-2 wrote
> While reading documentation for SET command, I observed that FROM
> CURRENT syntax and its description is missing from SET command's
> syntax page (http://www.postgresql.org/docs/devel/static/sql-set.html).
>
> Do you think that documentation should be updated for the same or
Amit Kapila-2 wrote
> On Tue, Oct 1, 2013 at 10:25 AM, David Johnston <
> polobo@
> > wrote:
>> Amit Kapila-2 wrote
>>> While reading documentation for SET command, I observed that FROM
>>> CURRENT syntax and its description is missing f
David Johnston wrote
> A paragraph cross-referencing where SET sub-commands exist has merit but
> since the main SET command does not accept FROM CURRENT it (FC) should not
> be included in its page directly.
It is strange that this actually does work - at least in 9.0 - given that
SET
Robert Haas wrote
> Unfortunately, the buildfarm
> isn't entirely happy with this decision. On buildfarm member anole
> (HP-UX B.11.31), allocation of dynamic shared memory fails with a
> "Permission denied" error, and on smew (Debian GNU/Linux 6.0), it
> fails with "Function not implemented", whi
Sameer Kumar wrote
> edb=# explain analyze select max(score) from student_score group by
> course;
This query returns 6 records. The window one returns 123,000. Why do you
expect these to have anywhere near the same performance or plan?
You can enable/disable indexes/scans to see what alternati
emanuel_calvo wrote
> %E = estimated rows
How would you expect this to work? This information seems mostly useless
without the context of a full EXPLAIN output.
> %T = temporal tables used
I am guessing you mean "temporary", not temporal - the later also being
known as "time oriented"
David
Tom Lane-2 wrote
> Craig Ringer <
> craig@
> > writes:
>> During my testing of Kohei KaiGai's row-security patches I've been
>> looking into how foreign keys should be and are handled. There are some
>> interesting wrinkles around FK cascades, the rights under which FK
>> checks execute, and abou
Jim Nasby-2 wrote
> Should that really matter in this case? ISTM we should always handle LIMIT
> before moving on to the SELECT clause…?
SELECT generate_series(1,10) LIMIT 1
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Feature-request-Optimizer-improvement
David Rowley wrote
> I'm sure in the real world there are many cases where a better choice in
> column ordering would save space and save processing times, but is this
> something that we want to leave up to our users?
Right now there is little visibility, from probably 99% of people, that this
is
Colin 't Hart wrote
> Methinks we should fix the documentation, something like:
>
> The command
>
> TABLE name
>
> is equivalent to
>
> SELECT * FROM name
>
> It can be used as a top-level command or as a space-saving syntax
> variant in parts of complex queries. Only the WITH, ORDER BY, LIMIT
Andrew Dunstan wrote
> A general ability to rename things would be good. In particular,
> restoring schema x into schema y or table x into table y would be very
> useful, especially if you need to be able to compare old with new.
compare old and new what? I would imagine that schema comparisons
Josh Berkus wrote
> Well, then we just need pg_restore to handle the "role already exists"
> error message gracefully. That's all. Or a "CREATE ROLE IF NOT EXISTS"
> statement, and use that for roles.
My only qualm here is if the exists check is based off of role name only.
If database "A" and
> >
> > Keep in mind that it's not about coding in C but mostly about figuring
> > out what a sane design out to look like.
> >
>
While I can straddle the fence pretty my first reaction is that we are talking
about "application" functionality that falls outside what belongs in "core"
PostgreSQL
On Apr 1, 2012, at 21:50, Jay Levitt wrote:
> Tom Lane wrote:
>> While you might not like the EDB installer, at least those
>> folks are active in the lists and accountable for whatever problems
>> their code has. Who in heck is responsible for the "homebrew"
>> packaging, and do they answer que
On Apr 1, 2012, at 13:14, Jay Levitt wrote:
> The Mac installation docs currently recommend the EDB one-click installer as
> the first choice. While this does install pgadmin and some other refinements,
> it also is fairly confusing to troubleshoot:
>
The items are not numbered and it is impo
Maciej Gajewski wrote
> I'm also afraid that with
> the extension I'd be left on my own maintaining it forever. While if
> this could go into the core product, it would live forever.
Clarification from the gallery: are we talking an extension or a custom
PostgreSQL build/fork?
If it is an extensi
Tom Lane-2 wrote
> "Joshua D. Drake" <
> jd@
> > writes:
>> I had a customer pulling their hair out today because they couldn't
>> login to their system. The error was consistently:
>
>> 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
>> authentication failed for user "user
>
Joshua D. Drake wrote
> On 06/07/2013 12:31 PM, Tom Lane wrote:
>> "Joshua D. Drake" <
> jd@
> > writes:
>>> On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
>>
>>> Why? That seems rather silly.
>>
>> The general poli
Cédric Villemain-2 wrote
> And also, first_value is a *window* function, not a simple aggregate
> function...
Per the documentation any aggregate function can be used with a WINDOW
declaration. The logical question is why are window aggregates special so
that the reverse cannot be true? In othe
Brendan Jurd wrote
> On 26 June 2013 03:17, Josh Berkus <
> josh@
> > wrote:
>> How should reviewers get credited in the release notes?
>>
>> a) not at all
>> b) in a single block titled "Reviewers for this version" at the bottom.
>> c) on the patch they reviewed, for each patch
I think some con
Benedikt Grundmann wrote
> A third party application we use generates SQL queries. Here is query it
> generated that broke today and for which I have a hard time arguing that
> the postgres behavior is correct (minimally the error message is
> confusing):
>
> =# create temporary table foo (b doub
Josh Berkus wrote
> On 07/12/2013 07:28 AM, Benedikt Grundmann wrote:
>> Thanks David,
>>
>> I like the fact that postgres is explicit in it's types. All I'm arguing
>> is that error message is misleading. And that I had a hard time
>> understanding why happened what happened. The part I was mis
soroosh sardari wrote
> Hi
>
> I want to know how an index is created and used.
> actually if you can show to me a simple start point, it would be great.
>
> Regards,
> Soroosh Sardari
In the documentation there is a table of contents and listed on that table
is a section named "Indexes".
David
David Johnston wrote
>
> soroosh sardari wrote
>> Hi
>>
>> I want to know how an index is created and used.
>> actually if you can show to me a simple start point, it would be great.
>>
>> Regards,
>> Soroosh Sardari
> In the documentation th
huxm wrote
> where there is a
> newline(\n) in the name.
I can't imagine why you would want to use non-printing characters in a name,
especially a database name. Even if the hba.conf file was able to interpret
it (which it probably cannot but I do not know for certain) client
interfaces are like
Minor request: could someone enlighten me as to why making the directory
location a compile-time option is undesirable. Packagers then can setup
whatever structure they desire when they compile their distributions. In
which case the discussion becomes what is a reasonable default and that can
be
Andres Freund-3 wrote
> Even trying to do this completely will guarantee that this patch will
> never, ever, suceed. There simply is no way to reliably detect problems
> that have complex interactions with the rest of the system.
>
> We can improve the detection rate of problems after some real wo
Josh Berkus wrote
> (this discussion concerns issue (D), file-per-setting vs. one-big-file)
>
> So the case of two sessions both modifying ALTER SYSTEM SET, and one
> succeeding for some-but-all-GUCS, and the other succeeding for
> some-but-not-all-GUCs, would not be user-friendly or pretty, even
On Sun, Aug 31, 2014 at 7:48 PM, Tom Lane wrote:
> David G Johnston writes:
> > Since "bucket" is the 'verb' here (in this specific case meaning "lookup
> the
> > supplied value in the supplied bucket definition") and "width" is a
> modifier
> > (the bucket specification describes an equal-width
On Mon, Sep 1, 2014 at 11:12 PM, Craig Ringer wrote:
> On 09/02/2014 09:40 AM, David G Johnston wrote:
> > Random thought as I wrote that: how about considering how pl/pgsql
> > functionality can be generalize so that it is a database API that
> > another language can call? In that way the serve
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake
wrote:
>
> On 09/02/2014 09:48 AM, Bruce Momjian wrote:
>
> As a case in point, EDB have spent quite a few man-years on their Oracle
>>> compatibility layer; and it's still not a terribly exact match, according
>>> to my colleagues who have looked
On Thu, Sep 4, 2014 at 5:13 PM, Robert Haas wrote:
> On Thu, Sep 4, 2014 at 1:18 PM, David G Johnston
> wrote:
> > Specific observations would help though that is partly the idea - I've
> been
> > more focused on clarity and organization even if it requires deviating
> from
> > the current gener
On Fri, Sep 5, 2014 at 6:27 PM, Marko Tiikkaja wrote:
> On 2014-09-05 11:19 PM, David G Johnston wrote:
>
>> Marko Tiikkaja-4 wrote
>>
>
> I probably couldn't mount a convincing defense of my opinion but at first
>> blush I'd say we should pass on this. Not with prejudice - looking at the
>> is
On Tue, Sep 9, 2014 at 12:03 PM, Robert Haas wrote:
> On Mon, Sep 8, 2014 at 6:20 PM, David G Johnston
> wrote:
> > On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] <[hidden
> > email]> wrote:
> >>
> >> On Thu, Sep 4, 2014 at 6:38 PM,
On Tuesday, September 23, 2014, Tom Lane wrote:
> David G Johnston > writes:
> > Can you either change your mind back to this opinion you held last month
> or
> > commit something you find acceptable - its not like anyone would revert
> > something you commit... :)
>
> Hey, am I not allowed to ch
On Tue, Sep 23, 2014 at 9:09 AM, Andres Freund
wrote:
> On 2014-09-22 21:38:17 -0700, David G Johnston wrote:
> > Robert Haas wrote
> > > It's difficult to imagine a more flagrant violation of process than
> > > committing a patch without any warning and without even *commenting*
> > > on the fac
On Tue, Sep 23, 2014 at 9:14 AM, Robert Haas wrote:
> On Tue, Sep 23, 2014 at 12:38 AM, David G Johnston
> wrote:
> > I'm of a mind to agree that this shouldn't have been committed...but I'm
> not
> > seeing where Stephen has done sufficient wrong to justify crucifixion.
> > Especially since eve
On Tue, Sep 23, 2014 at 1:30 AM, Tom Lane wrote:
> David Johnston writes:
> > My original concern was things that are rounded to zero now will not be
> in
> > 9.5 if the non-error solution is chosen. The risk profile is extremely
> > small but it is not theoretically z
On Tue, Sep 23, 2014 at 3:05 PM, Greg Stark wrote:
> Fwiw I agree with TL2. The simplest, least surprising behaviour to explain
> to users is to say we round to nearest and if that means we rounded to zero
> (or another special value) we throw an error. We could list the minimum
> value in pg_set
On Tue, Sep 23, 2014 at 10:11 PM, Gregory Smith
wrote:
> On 9/23/14, 1:21 AM, David Johnston wrote:
>
>> This patch should fix the round-to-zero issue. If someone wants to get
>> rid of zero as a special case let them supply a separate patch for that
>> "impro
On Thu, Sep 25, 2014 at 12:11 AM, Gregory Smith
wrote:
> On 9/24/14, 6:45 PM, Peter Eisentraut wrote:
>
>> But then this proposal is just one of several others that break backward
>> compatibility, and does so in a more or less silent way. Then we might
>> as well pick another approach that gets
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote:
> Gregory Smith writes:
> > I don't see any agreement on the real root of a problem here yet. That
> > makes gauging whether any smaller change leads that way or not fuzzy. I
> > personally would be fine doing nothing right now, instead waiting
On Thu, Sep 25, 2014 at 1:04 AM, Tom Lane wrote:
> David Johnston writes:
> > On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote:
> >> TBH I've also been wondering whether any of these proposed cures are
> >> better than the disease. The changes that can be argue
On Thursday, September 25, 2014, Gregory Smith
wrote:
> On 9/25/14, 1:41 AM, David Johnston wrote:
>
>> If the error message is written correctly most people upon seeing the
>> error will simply fix their configuration and move on - regardless of
>> whether they were proa
On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote:
> Robert Haas writes:
> > If we want the narrowest possible fix for this, I think it's "complain
> > if a non-zero value would round to zero". That fixes the original
> > complaint and changes absolutely nothing else. But I think that's
> > kind
On Fri, Sep 26, 2014 at 2:02 PM, Robert Haas wrote:
> On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> If we want the narrowest possible fix for this, I think it's "complain
> >> if a non-zero value would round to zero". That fixes the original
> >> complaint and c
On Fri, Sep 26, 2014 at 2:27 PM, Stephen Frost wrote:
>
> Agreed- they're independent considerations and the original concern was
> about the nonzero-to-zero issue, so I'd suggest we address that first,
> though in doing so we will need to consider what *actual* min values we
> should have for so
On Friday, September 26, 2014, Alvaro Herrera
wrote:
> Tom Lane wrote:
>
> > The impression I had was that Stephen was thinking of actually setting
> > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band
> > fashion, perhaps by adding GUC flag bits showing those as allowable
>
On Friday, September 26, 2014, Alvaro Herrera
wrote:
> David Johnston wrote:
> > On Friday, September 26, 2014, Alvaro Herrera >
> > wrote:
> >
> > > Tom Lane wrote:
> > >
> > > > The impression I had was that Stephen was thinking of act
>
>
>
>
>> We might as well allow a final trailing (or initial leading) comma on a
>> values list at the same time:
>>
>> VALUES
>> (...),
>> (...),
>> (...),
>>
>
>
> do you know, so this feature is a proprietary and it is not based on
> ANSI/SQL? Any user, that use this feature and will to
On Thu, Oct 23, 2014 at 8:51 AM, Andrew Dunstan wrote:
>
> On 10/23/2014 11:36 AM, David G Johnston wrote:
>
>> Andrew Dunstan wrote
>>
>>> On 10/23/2014 09:57 AM, Florian Pflug wrote:
>>>
On Oct23, 2014, at 15:39 , Andrew Dunstan <
>>> andrew@
>>> > wrote:
>>>
On 10/23/2014 09:27
On Fri, Oct 24, 2014 at 6:36 AM, Alex Goncharov <
alex.goncharov@gmail.com> wrote:
> On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane wrote:
>
>> (Of course, I'm not for the feature w.r.t. SQL either. But breaking data
>> compatibility is just adding an entire new dimension of trouble.
>>
>
> Anot
On Thu, Nov 13, 2014 at 10:55 AM, Merlin Moncure wrote:
> On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas
> wrote:
> > On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston
> > wrote:
> >>> Because I might be quite happy with 100 or 200 lines I can just scroll
> >>> in my terminal's scroll buffer, b
On Thu, Nov 13, 2014 at 5:47 PM, Tom Lane wrote:
> David G Johnston writes:
> > Tom Lane-2 wrote
> >> In the meantime, I assume that your real data contains a small
> percentage
> >> of values other than these two? If so, maybe cranking up the statistics
> >> target would help. If the planner
On Nov 17, 2012, at 9:18, Michael Giannakopoulos wrote:
> Hello guys,
>
> My name is Michail Giannakopoulos and I am a graduate student at University
> of Toronto. I have no previous experience in developing a system like
> postgreSQL before.
>
> What I am trying to explore is if it is possib
On Nov 27, 2012, at 5:25, Dimitri Fontaine wrote:
>
> So my proposal for the current feature would be:
>
> ALTER MATERIALIZED VIEW mv UPDATE [ CONCURRENTLY ];
> UPDATE MATERIALIZED VIEW mv;
>
> The choice of keywords and syntax here hopefully clearly hint the user
> about the locking behavio
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Dimitri Fontaine
> Sent: Tuesday, November 27, 2012 10:03 AM
> To: Kevin Grittner
> Cc: Pavel Stehule; Peter Eisentraut; Pgsql Hackers
> Subject: Re: [HACKERS] Materia
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Monday, December 10, 2012 3:29 PM
> To: Pavel Stehule
> Cc: PostgreSQL Hackers; Alvaro Herrera; Tom Lane
> Subject: Re: [HACKERS] enhanced erro
> > The more secure behavior is to allow entry of data which will not be
> > visible by the person doing the entry.
>
> I don't think it is that simple. Allowing inserts without regard for row
level
> restrictions makes it far easier to probe for data. E.g. by inserting rows
and
> checking for uni
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Marko Tiikkaja
> Sent: Friday, December 21, 2012 10:53 AM
> To: Tom Lane
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] PL/PgSQL STRICT
>
> On 12/21/12 4:49 PM
Tom Lane-2 wrote
> Gurjeet Singh <
> singh.gurjeet@
> > writes:
>> Can somebody explain why a standalone count(*) returns 1?
>> postgres=# select count(*);
>> count
>> ---
>> 1
>> (1 row)
>
> The Oracle equivalent of that would be "SELECT count(*) FROM dual".
> Does it make more sense
On Jul 30, 2012, at 12:33, Thom Brown wrote:
> On 30 July 2012 17:19, Pavel Stehule wrote:
> Hello
>
> I seen nice trick based on window function
> http://stackoverflow.com/questions/11700930/how-can-i-trim-a-text-array-in-postgresql
>
> but isn't it example of wrong evaluation? Result of row
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Monday, August 20, 2012 5:04 PM
> To: Jeff Davis
> Cc: Vlad Arkhipov; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] temporal support patch
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Saturday, August 25, 2012 12:46 PM
> To: David Johnston
> Cc: Jeff Davis; Vlad Arkhipov; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] temporal support patch
>
> On Mon, Aug 20
> -Original Message-
> There really needs to be some way to specify that when an expression is
> evaluated for each row in a set, a function used within that expression is
not
> optimized away for some rows. Fortunately we have a way:
>
> http://www.postgresql.org/docs/9.2/interactive/sql
> -Original Message-
> >> | VOLATILE indicates that the function value can change even within a
> >> | single table scan, so no optimizations can be made.
> >> | Relatively few database functions are volatile in this sense; some
> >> | examples are random(), [...]
>
> > What are the argu
> -Original Message-
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
> Sent: Wednesday, September 19, 2012 5:51 PM
> To: k...@rice.edu; David Johnston
> Cc: 'Florian Schoppmann'; 'Robert Haas'; pgsql-hackers@postgresql.org;
'Tom
>
> > I did like the alternative idea upthread of UUIDs for types which
> > would give them a virtually unlimited space.
>
> Yeah, me too. That doesn't require a centralized authority (hence, no
> debates here about whether a given extension is important enough to merit
> an allocation of a give
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Noah Misch
> Sent: Tuesday, October 02, 2012 3:02 PM
> To: Craig Ringer
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] Raise a WARNING if a REVOKE affects nothing?
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Andrew Dunstan
> Sent: Thursday, October 11, 2012 8:52 PM
> To: Daniel Farina
> Cc: Joshua D. Drake; Josh Berkus; Simon Riggs;
pgsql-hackers@postgresql.org
> Subject:
On Oct 12, 2012, at 22:13, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> [ shrug... ] You're attacking a straw man, or more precisely putting
>> words into my mouth about what the percentage-based thresholds might be.
>> Notice the examples I gave involved update percentages q
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Simon Riggs
> Sent: Sunday, October 14, 2012 5:30 PM
> To: Tom Lane
> Cc: Greg Stark; Peter Geoghegan; PostgreSQL-development
> Subject: Re: [HACKERS] Deprecating RULE
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Monday, October 15, 2012 7:13 PM
> To: Andres Freund
> Cc: pgsql-hackers@postgresql.org; Thom Brown; Phil Sorber
> Subject: Re: [HACKERS] [WIP] pg_pin
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Abhijit Menon-Sen
> Sent: Sunday, October 21, 2012 5:45 AM
> To: Tom Lane
> Cc: P. Christeas; pgsql-hackers@postgresql.org
> Subject: [HACKERS] Re: [PATCH] Enforce tha
1 - 100 of 196 matches
Mail list logo
