send" on this email light dawned: the code that
calls our "creates db connection" function is not checking the return
value correctly, and PQreset fails because our that function wipes out
the connection object (assuming that it cannot be used).
Sorry to waste bandwidth.
Geoff
eeded, is that the
problem? Will PQreset only work on a connection that had previously
connected successfully?
If that _is_ the case, is there a way to tell up-front whether this is
the case (so I can retry PQconnectdb instead of calling PQreset)?
Thanks
Geoff
--
Sent via pgsql-general m
ents where source_id = $SOURCE_ID and ineffective_date is
null" | while true; do
if [ $a -gt $biga ] ; then
biga=$a
fi
if ! read a; then echo $biga; break; fi
done
)
A mess, but it works.
To be honest, by the time you've got to this level of complexity you
probably sho
suing the product
design, but I'm not really surprised that the MTBF is worse: if the
shingled disk must write some tracks twice for each individual track write,
it seems logical that there will be more write stress and therefore
shortened lifespan, no?
Geoff
ell script. If you have strong experience in a particular language then
you should use that language, and invest time in optimising your data
structures and developing faster algorithms.
Geoff
ef, is likely to provoke exactly that sort of negative
pushback, and does little but make your life harder.
Geoff
On 3 March 2017 at 12:17, Sven R. Kunze wrote:
> On 03.03.2017 11:43, Geoff Winkless wrote:
>
> One alternative would be to make to_date accept all language variants of
> months simultaneously. A quick search of google suggests that there aren't
> any overlaps between lan
ity in that what ANSI SQL would reject as not-a-date
might be parsed as a date. I'm not in a position to judge if either of
those would be acceptable.
Geoff
locale is specified in the format string).
The only way to do it would be to add to_date(string, string, string) where
the third string specifies the locale, at which point I don't really see
why you would gain anything over creating your own UDF.
Geoff
Would the fact that you can have month names in to_date strings make it
dependent on current locale?
Geoff
table
todate function and thinks they can use it for something else.
Geoff
On 26 February 2017 at 16:09, Adrian Klaver
wrote:
> On 02/26/2017 07:56 AM, Geoff Winkless wrote:
> > On 26 February 2017 at 10:09, Sven R. Kunze > <mailto:srku...@mail.de>>wrote:
> >
> > >>># create index docs_birthdate_idx ON docs using
Date functions are inherently not immutable because of timezones. Your
solution of using to_timestamp doesn't help because it automatically
returns a value in WITH TIMESTAMP. Do you get anywhere by using
"::timestamp without time zone" instead, as suggested here?
https://www.postgresql.org/message-id/4E039D16.20704%40pinpointresearch.com
Geoff
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
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
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
#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
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
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
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
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
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)
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
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
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:
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
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
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
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
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
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
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
On 17 May 2016 at 10:22, Achilleas Mantzios
wrote:
> On 17/05/2016 12:16, Geoff Winkless wrote:
>>
>> On 17 May 2016 at 09:34, Pierre Chevalier Géologue
>> wrote:
>>>
>>> On this matter, I hear *very* often from such guys that the only reproach
>>
sort of Holy Grail that would definitely
> convince them. A standard client tool that would come with any PostgreSQL
> installation would please them. Some sort of psqlGUI, I guess.
Why reinvent the wheel? I would say that putting the development
effort into the OpenOffice Base app would be t
r the queries you run to
optimise to a particular DBMS.
But you're right, if you've started out well, it will at least
minimise the amount of change.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
erstand the
business rules and the data behind it, and the application developers
can ask those experts to do the heavy lifting for them. Having to
persuade management that they should no longer be able to connect the
database to MS Access and make changes that way will usually put an
end to that p
topic in the
list with this? I'm sure that anyone who's interested in this will
have seen it in the thread you created that was actually marked with
it in the subject.
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 April 2016 at 12:29, Geoff Winkless wrote:
> To find students with no exam today (the other point of your argument):
>
> SELECT student_id, name
> FROM student
> LEFT JOIN exam USING(student_id)
> WHERE exam_date=CURRENT_DATE AND exam.student_id IS NULL;
*sigh* problem w
ent):
SELECT student_id, name
FROM student
LEFT JOIN exam USING(student_id)
WHERE exam_date=CURRENT_DATE AND exam.student_id IS NULL;
Not really sure what the issue is with either of those. Once learned,
they're both very easy and straightforward.
Geoff
--
Sent via pgsql-genera
1 intersect select 1;
> ?column?
> --
> 1
> (1 row)
>
> postgres=# select intersect select;
> --
> (2 rows)
See above.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
umbers in the tens of
thousands of records at most (and if it scales to tens of millions
then great).
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ww.monetdb.org/content/citusdb-postgresql-column-store-vs-monetdb-tpc-h-shootout
" the margin by which MonetDB outperforms cstore_ftw shows that only
switching storage models alone is probably not enough"
Geoff
(Disclaimer: I've no connection to MonetDB in any way)
--
Sent via pgsql-ge
ke)
field2-16 which are used in similar queries.
I'll stick with enable_seqscan=off, it seems to be doing the trick;
thanks though.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
lues in pa.field1, so I suppose it might seem more
attractive to the planner than it should do (that's more unique values than
there are scdate entries).
I might just set enable_seqscan to false and leave it at that. It makes me
unhappy though.
Geoff
creating a subquery out of the legs dataset in the hope that
that would help but that made no difference either.
Geoff
s no difference.
Table pa has 7522676 rows, 4834042 of which have field1 NULL, so it's
absolutely not reasonable to expect this to be an optimal strategy.
Any suggestions as to how I can improve this query?
Thanks :)
Geoff
ood on that perfect distribution but behave
better on data that is not perfectly distributed.
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 12 March 2016 at 18:43, Peter J. Holzer wrote:
> On 2016-03-08 10:16:57 +0000, Geoff Winkless wrote:
>> On 7 March 2016 at 20:40, Peter J. Holzer wrote:
>> > As Tom wrote, the estimate of having to read only about 140 rows is only
>> > valid if sc_id and sc_date a
s still not too bad (1.3 seconds or so).
The point is that to assume, knowing nothing about the data, that the
data is in an even distribution is only a valid strategy if the worst
case (when that assumption turns out to be wildly incorrect) is not
catastrophic. That's not the case here.
Ge
the planner than (scdate,sc_id) and why the index that was
transferred from the Other Database that we've migrated from isn't
useful here :)
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 March 2016 at 16:44, Tom Lane wrote:
> Geoff Winkless writes:
>> But as far as I can see, apart from the absolute extremes, the
>> index-only scan is _always_ going to be quicker than the index+table
>> scan.
>
> Well, that is a different issue: what does the
cid-only index
suffers.
And the real advantage: at the extremes, the index-only worst-case is
minimally worse than the best case. Whereas the worst-case of the
index-scan-plus-table-compare method is horrific.
I don't believe you need any further statistics than what is currently
available to
On 7 March 2016 at 14:51, Tom Lane wrote:
> Geoff Winkless writes:
>> So it seems that it should in fact be usable after all. So I'm still
>> stumped as to why the (scdate,sc_id) index isn't used :(
>
> Because the other way is estimated to be cheaper. The es
e
index, even ignoring the scdate/sc_id index.
So I'm afraid I'm fully back in the "I still don't get it" column.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
visits to the table proper, but they do not
reduce the portion of the index that has to be scanned.
So it seems that it should in fact be usable after all. So I'm still
stumped as to why the (scdate,sc_id) index isn't used :(
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@
ues in the table (unless the index is larger than
the table itself, I suppose).
I might suggest that perhaps the rule should be relaxed so that an
inequality constraint does not stop the subsequent columns being used
in an index-only scan.
That assumes that I've not completely misunderstood, of
On 7 March 2016 at 11:48, Victor Yegorov wrote:
> 2016-03-07 13:38 GMT+02:00 Geoff Winkless :
>>
>> # EXPLAIN (ANALYZE,BUFFERS) SELECT MIN(sc_id) FROM legs WHERE scdate
>> BETWEEN 20160219 AND 20160221;
>
>
> Will it help if you'll add `count(*)` to your query
he_size is set to 3GB (but changing it wildly up or down
doesn't change anything), shared_buffers is 1GB, work_mem is 5242kB
(but changing to anything up to 1GB makes no difference).
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
in place of !=; quite apart from being ANSI
(which I hadn't realised) it has the advantage over != that I get
nostalgia for 1983 and BASIC :)
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type casts.
Time: 0.608 ms
db=# SELECT 'yes' WHERE 1<>-1;
?column?
--
yes
(1 row)
I get this with fieldnames too, so it's not just a parsing-litera
On 29 Feb 2016 22:47, "Kevin Grittner" wrote:
>
> On Mon, Feb 29, 2016 at 2:10 PM, Geoff Winkless
wrote:
>
> > I'm not really sure what changes I could make that would make one
> > index that's ostensibly equivalent to the other not be attractive to
>
be attractive to
the planner though. I can mess with those figures but as I said before
the only one that flicks the switch is to change effective_cache_size
to 8GB, which makes no sense to me.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to yo
Just as a continuation of this, I can set effective_cache_size to 64MB
and it will still use the single-column index, but PG flatly refuses
to use the multicolumn index without effective_cache_size being an
unfeasibly large number (2x the RAM in the machine, in this case).
Geoff
--
Sent via
On 29 February 2016 at 14:07, Geoff Winkless wrote:
> On 29 February 2016 at 14:06, Jim Mlodgenski wrote:
>> No they are not the same. When you don't include a unit for
>> effective_cache_size, it defaults to page size so you're saying 2146435072 *
>> 8K
>
&g
On 29 February 2016 at 14:06, Jim Mlodgenski wrote:
> No they are not the same. When you don't include a unit for
> effective_cache_size, it defaults to page size so you're saying 2146435072 *
> 8K
Hah.
Thanks Jim, like I said I was sure I'd be missing something :)
Ge
ze value not
expecting the human-readable value?
Thanks for suggestions
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
k of what worked and what didn't.
Sorry for wasting time.
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
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
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
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
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
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
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
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 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 (
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
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
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
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
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&#
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
" 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
#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
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
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
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
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
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.
&
; 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
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
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
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
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
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
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
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
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
1 - 100 of 187 matches
Mail list logo
