I'm working on a database project and we're starting to look at open
source alternatives to Oracle. The group I'm working for is keen to
find a suitable database that has passed the common criteria
evaluation at some level. I know an older version of PostgreSQL for
Linux was evaluated at EAL 1 in
> Sounds like you already have something listening on 5432. Perhaps
> another verison of PostgreSQL already installed?
>
Thats what I thought, but a port scan tells me that the port is closed.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscripti
my to_date function but none of them made a difference.
Thanks!
Geoff
ed to use 100%
fillfactor and avoid clustering on ZFS. Can anyone comment on this?
Thanks,
Geoff
On Thu, Apr 16, 2015 at 4:56 PM, Qingqing Zhou
wrote:
> On Thu, Apr 16, 2015 at 5:09 AM, Geoff Speicher
> wrote:
> > Therefore one might posit that PostgreSQL should be configured to use
> 100%
> > fillfactor and avoid clustering on ZFS. Can anyone comment on this?
> &g
t; block
> as well as (at least) one index block per index involved.
Your last three words. I was ignoring the obvious (and likely) scenario of
when more than one index needs to be updated.
fillfactor<100% with COW still gets the win.
Thanks!
Geoff
Can you not just CROSS JOIN it to generate_series(1, 8)?
On 22 April 2015 at 14:14, Marc-André Goderre wrote:
> Hi all,
> I'm having difficulties to create a function that should execute X time
> the same query and return their results as a single table.
> I tried this way but it don't work :
27;re trying to achieve:
SELECT COUNT(*), id FROM bg GROUP BY id ORDER BY id;
?
Geoff
On 7 May 2015 at 11:54, Thomas Kellerer wrote:
> Geoff Winkless schrieb am 07.05.2015 um 12:39:
> > in Postgres (unlike MySQL) you can't order a list of values by a column
> you haven't selected.
>
> Of course you can, just not when you are aggregating.
>
>
gs, feel free to ask for help on the GitHub page:
https://github.com/GeoffMontee/tds_fdw
Good luck!
Thanks,
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, May 18, 2015 at 10:28 AM, Filip Rembiałkowski
wrote:
> Thank you Geoff.
>
> Actually I have a problem - maybe you can point me in the right direction?
>
> CREATE EXTENSION tds_fdw;
> CREATE EXTENSION
>
> CREATE SERVER ms FOREIGN DATA WRAPPER tds_fdw OPTIONS (se
On Mon, May 18, 2015 at 11:24 AM, Geoff Montee wrote:
>
> The NOTICE right before the error might provide useful information:
>
> NOTICE: DB-Library notice: Msg #: 40508, Msg state: 1, Msg: USE
> statement is not supported to switch between databases. Use a new
> connecti
ors and functions in the clauses must
be IMMUTABLE as well."
I'm guessing that postgres_fdw sees that one of your function calls is
IMMUTABLE, so it thinks it is unsafe to push-down. It is probably your
call to NOW(). You might want to try replacing that with a literal
somehow, if you can
ns exist in the row to return a row count.
Geoff
o way of defining what
"*" refers to in this instance. You don't *need* to define what (*) is in
order to tell that there's exactly one row in it.
Geoff
, the other errors are simply configure
trying to work out which compiler you're running - -V and -qversion simply
aren't valid flags to gcc - so those "error" lines are expected result.
Geoff
On 11 June 2015 at 15:35, Yves Dorfsman wrote:
> On 2015-06-11 08:20, Geoff Winkless wrote:
> > On 11 June 2015 at 15:17, Marc Mamin > <mailto:m.ma...@intershop.de>>wrote:
> >
> > >But COUNT(*)
> > >
> > >does have meaning -
d alloc is larger than it needs to
be, but even if it were fixed you would still run into problems further
down the line managing values of that size.
Geoff
authorization. So in the extremely unlikely event that the random key isn't
unique, it doesn't matter. That's not a workaround, it's good design.
You're asking for a feature that is completely unnecessary and is easily
resolved. UPSERT is designed for a situation which is neither.
Geoff
y, the workaround in the above case (even if you don't want to
change the primary key) is trivial - as you yourself described.
Geoff
ch suggests that random sequences are not great for indexes
because of the resultant "keyspace fragmentation". I'm assuming that means
a low number of nodes in the btree leafs, so an increase in memory usage
for the index?
Just a thought.
Geoff
eate more leaf nodes than you
require (in order to leave plenty of blank space, and even if you do that
you will probably end up with uneven fill, which means some searches will
be slower than others) or you end up having to refactor all of your nodes
every time you insert a value.
Geoff
iest way to achieve what you want.
I'm sorry to be harsh (again) about this but adding extra complexity to the
PG system to achieve something that is _easily_ achieved through the
existing mechanisms isn't something that is likely to get widespread
support.
Geoff
ELETE.
>
I don't think anyone is suggesting that it is.
Otherwise there wouldn't be much point having it.
Geoff
On 22 July 2015 at 16:55, Joshua D. Drake wrote:
>
> On 07/22/2015 08:42 AM, Geoff Winkless wrote:
>
>> On 22 July 2015 at 16:32, Joshua D. Drake > <mailto:j...@commandprompt.com>>wrote:
>>
>> This is actually wrong. The end result is the same but it d
10}'::jsonb->>'a' - 5;
to return '5' - since left-to-right precedence would make ->> run before
the subtraction; however I get:
ERROR: invalid input syntax for integer: "a"
LINE 1: select '{"a":10}'::jsonb->>'a' - 5;
So what precedence level is ->> actually running at?
Or am I missing something?
Cheers
Geoff
he precedence of
the ->> operator.
As far as I can see the ->> operator has predence below '- +' but above
'IS', but there's no entry for it in that place in the precedence table.
Geoff
On 5 August 2015 at 14:52, Tom Lane wrote:
>
> The first compatibility item in the 9.5 release notes: we changed
> the precedence of IS and some other things. You need to be reading
> the 9.5 version of the precedence table.
Doh. Sorry, I'm an idiot.
Surely just
CASE picked WHEN 'y' THEN load_id ELSE NULL END
or
CASE WHEN picked='y' THEN load_id ELSE NULL END
?
On 25 September 2015 at 12:08, Ramesh T
wrote:
> CREATE UNIQUE INDEX idx_load_pick ON pick (case picked when picked='y'
> then load_id else null end );
>
> how can i convert case
Well you could use
SELECT LENGTH(REGEXP_REPLACE('123-987-123', '(([^-]*-){2}).*', '\1'));
Not pretty, but it works.
Geoff
On 15 October 2015 at 15:05, Ramesh T wrote:
> '123-987-123' it is not fixed some times it may be '1233-9873-123-098'
ctionary not do what you want?
http://www.postgresql.org/docs/current/static/textsearch-dictionaries.html#TEXTSEARCH-THESAURUS
Geoff
tem
> where only one read/write operation executes at a time.
>
> Can you tell me if this is correct?
>
There's a similar thread here that might be worth a read:
http://postgresql.nabble.com/concurrent-IO-in-postgres-td3316768.html
Geoff
;
> Any ideas?
>
I believe that I just committed a fix for this to tds_fdw. Can you
please pull the latest commit from the tds_fdw repo and then try
compiling again?
Thanks,
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
n relies on them taking things that they don't deserve while
they treat customers and employees with similar levels of arrogance.
Frankly I'd rather there were as many levels of separation as possible
between me and them: they and Oracle are welcome to each other, it seems
like a marriage made in heaven.
Geoff
7;s
worth").
G
On 27 July 2016 at 17:11, Andrew Sullivan wrote:
> On Wed, Jul 27, 2016 at 04:51:42PM +0100, Geoff Winkless wrote:
> > technical reasons. Most developers will harp on at their boss about how
> > terrible their current database is and how performs
> > muc
catastrophic bug in the new version that causes your live system to fall
over but
which
didn't appear on your test system, and then revert to a working version?
I'd say that's a fairly useful feature, limited or not.
Geoff
unction
All well and good, and I'm happy enough to change the query's GROUP BY
to include the table name, but it's confusing me how it works OK on
all servers except one.
Is there some configuration option I'm missing?
Thanks!
Geoff
--
Sent via pgsql-general mailing list
s way. If not I'll have to look more closely at the table
defs, although I thought I had checked they were the same.
Geoff
task is to work out how on earth the server ended up with its
results table different to all the others...
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ion should drop any table with the same name that has been
created by another transaction.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 6 Oct 2016 12:06 p.m., "Francisco Olarte" wrote:
>
> On Thu, Oct 6, 2016 at 11:21 AM, Geoff Winkless
wrote:
> > DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
> >
> > Occasionally this produces
> >
> > ERROR:
cally bankrupt: you can quite happily test for
existence without requiring any sort of atomic DROP, if that's your
intention.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e is "DROP TABLE", whether it dropped or not, shows this.
> And the notice is not the reason it is not done
> at commit time, the reason is the one you said, action must be taken
> when you issue the command, not a magic convenient time in the future
I've no idea what thi
On 6 October 2016 at 16:47, Kevin Grittner wrote:
> I recommend using a transactional advisory lock to serialize these.
Thanks Kevin, that does seem like the best (although not particularly
pleasant) solution.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
st. The fact that its
>> RETURN value is "DROP TABLE", whether it dropped or not, shows this.
>
> What function?
I'm mixing up terminologies (statement, not function). I'm still
talking about "DROP TABLE IF EXISTS" here.
Geoff
--
Sent via pgsql-general
de (as per Kevin), or (I suppose) I could do an
individual transaction to CREATE TABLE IF NOT EXISTS as a separate
transaction before I start; it's just something that caught me out
because I didn't expect it to be a problem.
Geoff
--
Sent via pgsql-general mailing list (pgsql-gene
ore transaction local data.
The data isn't transaction-local. Having said that, the _actual_
pattern is much worse than that, but it's not my design, I just have
to work with it.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
E EXISTS (SELECT FROM games WHERE player1=uid OR player2=uid)
although as Tom says, it's dubious whether that will result in a
significant speedup.
Geoff
#SQL-DISTINCT
The DISTINCT ON expression(s) must match the leftmost ORDER BY expression(s).
The ORDER BY clause will normally contain additional expression(s) that
determine the desired precedence of rows within each DISTINCT ON group.
Does the problem go away if you do that?
Geoff
o more readable.
FWIW you can resolve half of the CASEs by resolving it in the join to
s1 and s2 - so
LEFT JOIN words_social s1 ON s1.uid = in_uid
LEFT JOIN words_social s2 ON CASE WHEN g.player1 = in_uid THEN
g.player2 ELSE g.player1
etc
Geoff
--
Sent via pgsql-general mailing list (pgsql-g
On 31 October 2016 at 15:21, Geoff Winkless wrote:
> LEFT JOIN words_social s1 ON s1.uid = in_uid
> LEFT JOIN words_social s2 ON CASE WHEN g.player1 = in_uid THEN
> g.player2 ELSE g.player1
Ugh.
Of course I meant
LEFT JOIN words_social s1 ON s1.uid = in_uid
LEFT JOIN words_social s2
s by just JOINing
the other tables via a CASE anyway.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to c3), other than (obviously!) copying the
literal values into the VALUES string?
To be clear, the SQL is generated dynamically based on data, so I can't
just create a view for the calculated column (it won't always be
calculated!).
Thanks!
Geoff
could be used that
way. Thanks!
Geoff
PK for the WHERE clause...)
So
INSERT INTO test (c1, c2) VALUES (3, 7); UPDATE test SET c4=c1*c2 WHERE
c1=3; UPDATE test SET c5=c4*c3 WHERE c1=3;
Not as neat (nor probably as efficient), and a bit of a pain to have to
include the PK each time, but does at least achieve what I need.
Thanks again for the insights, always good to learn something :)
Geoff
On 17 November 2015 at 14:31, Adrian Klaver
wrote:
> On 11/17/2015 01:14 AM, Geoff Winkless wrote:
>
>> INSERT INTO test (c1, c2) VALUES (3, 7); UPDATE test SET c4=c1*c2 WHERE
>> c1=3; UPDATE test SET c5=c4*c3 WHERE c1=3;
>>
>
> Could the above not be shortened to?
On 26 November 2015 at 12:43, Sterpu Victor wrote:
> Hello
>
> I need to order an array using another column in table ad_query_join_select.
>
> I need something like this but this is not a valid SQL:
> SELECT array_to_string(array_agg(aqjs.id *ORDER BY aqjs.to_left*), ',')
> AS str, aq.name
> FRO
> There are doubles because of the join aqjs3 witch is producing this
> problem.
> Can I make it so the children ID's are unique?
>
>
Well if you can live with losing the to_left ordering, then you could just
do
SELECT STRING_AGG(DISTINCT CAST(aqjs1.id AS VARCHAR), '') AS children
...
no?
Geoff
the
"children" set to be ordered numerically? You can still order the outer
query by whatever you like, or you can order the aggregate by the values
themselves, it's just the DISTINCT inside the aggregate query requires that
an internal ORDER includes the ordering term in the result.
Geoff
On 29 November 2015 at 20:51,
I
wrote:
> Well you could look at the intarray extension and a combination of
> array_agg, uniq() and
> *string_to_array*:
Mind blip, apologies, obviously I meant array_to_string :)
Geoff
Gosh, I've got a lot of love for CoCs; I've heard great things, really
good things, some things, about CoCs, that some of them have been
really helping in a yuge way with some fantastic projects. Sometimes
some people, a lot of people, have said that I could write a CoC, and
you know, I think they'
re is a -docs list, after all. But since I'm able to simply ignore
and delete those posts that don't interest me, I didn't really see any
point in saying anything.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
27;ve been called out previously for using misogynistic
language on the lists.
Apologies for missing your point :)
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
th less expertise. I know that's sort-of
implied by the "any person who is willing to contribute" phrase but I
would say that being explicit about it is more likely to encourage
non-contributors to contribute than what's been arrived at so far.
Geoff
--
Sent via pgsql-general ma
de they've modified relies on the
specific way the code worked before.
> because then they'd expect preferential treatment because they don't know C
> and be constantly badgering everybody for help.
Someone coming on to the mailing lists and asking for help with newbie
stuf
On 13 January 2016 at 13:55, Chris Travers wrote:
> People *can* take offense when you say their code is not good enough,
> particularly when it is true,
Well I would hope that you wouldn't say so if it wasn't. :)
My point is that most people won't be posting code here going "this is
a bit crap,
On 13 January 2016 at 14:15, Regina Obe wrote:
> He can also make fun of my tabbing style and say "What's wrong with your
> editor? Perhaps you need to use a different one or change the settings"
You're right, what we've really been missing all these years
or not. On the flip side, I imagine that being
that well-known brings positives (job offers, paid - or at least
expenses-paid in nice locations - speaking engagements etc) in return.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
at the opinion
is a violation of the CoC, without making any judgement about the
person making that statement :)
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
hreads about something about which the majority have
no interest to a mailing list where it might reasonably be considered
offtopic, and telling anyone who complains that they can "just ignore
them"?) would also not be tolerated.
But maybe I'm just being facetious :)
Geoff
--
Sen
e group of people" can be whipped up from a tiny minority.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ying crowd decide your fate rather than
codifying acceptable behaviour?
The Dark Ages called, they want their Justice model back :)
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
asonableness is fairly well established in most
legal systems.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 21 January 2016 at 12:36, Chris Travers wrote:
> I still side with the Scandinavian approach of passing general laws and
> trusting judges to apply them in line with moral rather than purely legal
> principles.
I believe that it's generally accepted that people will unconsciously
apply their o
haven't bothered to read the whole thread, but why don't you do it
Right instead?" is pretty insulting, don't you think?
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
; with time.
You've given no clear evidence as to a) whether that's true or b) how
a CoC will actually help to achieve that.
I believe that it's right and proper that the direction of Postgres is
defined by the people who spend their time writing it. If, in ten
years' time, some di
On 22 January 2016 at 12:08, FarjadFarid(ChkNet)
wrote:
>
> But Geoff, Without knowing what problems people are facing in their
> businesses no product will ever stay relevant to end users for long.
Then end users will move on, or get involved. That's also right and proper.
&
On 22 January 2016 at 13:09, FarjadFarid(ChkNet)
wrote:
>>Geoff wrote
>>> Then end users will move on, or get involved. That's also right and proper.
> You rather see postgresql ,as a product, die but you want to no one have an
> input. Just yours.
Now I'm bei
ly way in which I can see it doesn't align with the
Contributor Covenant is that the CoC doesn't consider someone's
personal opinions, either private or expressed outside the Postgresql
arena, to be the responsibility of the Postgres team.
Geoff
--
Sent via pgsql-general mailing
are entitled to require the postgres
team to commit to behave in a way with which they are uncomfortable is
actively unwelcome. Why is that unreasonable?
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e welcome to hold that view, but you are not welcome to express
it in a personal derogatory way. At no point does the CoC say "you can
come here and _express_ your opinions in an unfettered manner".
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
#x27;t speak for anyone else but personally I
hope it brings you the joy you seek.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
" do not, unless you meant "IMO" rather than
"IME"
> Limiting the policy to community forums is insufficient for making people
> feel safe.
> This is the whole reason for v1.3.0 of the Contributor Covenant:
It was made clear very early on in the discussion th
on. Everyone is entitled
to the same level of protection, whatever their race, gender
alignment, sexuality or whatever, and that includes us white
middle-class men, however guilty you appear to feel the need to be
about being one.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgres
think the author of the preceding article is lying, google the
> combination of "groped" and "Linux conference". Women are the minority
> at these conferences, yet many more hands reach out and grab them.
And there are laws designed to stop that sort of behaviour. It&#
reports
> expeditiously, then I don’t see how the proposed CoC get us there.
It doesn't help that you appear to be hearing and not listening.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 24 January 2016 at 00:15, Steve Litt wrote:
> On Sun, 24 Jan 2016 00:00:27 +
> Geoff Winkless wrote:
>> Did I say we all need equal protection? No. I said we're all entitled
>> to the same level of protection.
>
> The preceding two sentences form a di
grees
with your lifestyle and makes generalised statements about that
lifestyle which offend you is not abusing you, and yet as far as I can
see that is what the Covenant has been used to combat (and it appears
designed specifically so to do).
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
half of or
against one of the core team), and to advise on the exact liabilities
and responsibilities of whoever implements the CoC.
I'm sure that'll be fine, yes?
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e know that we are covered against any
potential legal issues" would be prohibitively expensive.
If someone's prepared to put themselves in a position to overcome that
issue then it's just an argument over points of view, really.
Geoff
--
Sent via pgsql-general mailing list (
x27;t
> care, won't care, or agrees with the right for the Russian conference to
> have those dancers. It was done so because -core wants all people to feel
> welcome.
Apart from those people who think that topless dancers are fine? But
who cares about them, cos they're just
e they simply didn't want to hear
them. My current attitude is a direct consequence of theirs.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Wow. And I was annoyed with myself that _I'd_ wasted so much time by
being drawn into this nonsense.
It appears that the only way to deal with the covenant and its
proponents is just to say "lalalalalala can't hear you" because they
will not listen to reason or take on board that any of what they
it's unnecessarily confusing to start suggesting that
there's some equivalency when you then need to clarify that actually
they're not really equivalent.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 7 February 2016 at 21:04, Tom Lane wrote:
> Geoff Winkless writes:
>> On 31 January 2016 at 19:53, David G. Johnston
>> wrote:
>>> A PRIMARY KEY enforces a UNIQUE, NOT NULL constraint and additionally allows
>
>> I would just remove the whole paragraph. A pr
infer the type from the string when one is returned
and from an explicitly cast string that _isn't_ returned, but can't
infer the type from the non-cast version, and b) it needs a type for
NULL at all (since any NULL is going to be treated the same).
(running 9.5, if it matters
can be the case,
because the type it tries to coerce the NULL into is defined by the
second argument (which must be COALESCE-specific behaviour, I would
think).
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
infer the type from the string when one is returned
and from an explicitly cast string that _isn't_ returned, but can't
infer the type from the non-cast version, and b) it needs a type for
NULL at all (since any NULL is going to be treated the same).
(running 9.5, if it matters
nto anything (even if you
ignore that NULL is, as far as I know, equivalent, no matter what its
type), because as far as COALESCE is concerned the NULL can be
instantly ignored.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s, that was the whole point.
> but that's not
> going to make any difference for parse-time determination of what
> type the COALESCE() will return.
But when the gwtest subquery _does_ return a value it works, so the
problem can't be parse-time determination, can it?
G
1 - 100 of 187 matches
Mail list logo
