constants,
https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
(see 4.1.2.6 about numeric constants). Numeric constants don't start
out as "unknown" the way quoted literals do, because it's possible to
make a reasonable determination of their type
s cat.
Somebody could write an encoding converter that translates one
of these ASCII-unsafe representations into an ASCII-safe format
to be used internally in the backend, and then the reverse on
the way out.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-gene
The amount of
work involved, and the ongoing hazard of security bugs that would ensue,
is just prohibitive.
We do however support them as client-side encodings with automatic
translation to and from Unicode on the server.
regards, tom lane
--
Sent via pgsql-general mailing list (
n your first example the array can be seen to be int[] and 7 is taken
to be type int, so only "anyarray || anyelement" works. In the second
case it's looking at "int[] || unknown", and the relevant heuristic is
to assume that the "unknown" is the same type as the operator's other
in
in the wild that still
depends on it.
Also, moving from v2 to v3 per se just isn't very hard, if you aren't
worried about making use of new-in-v3 protocol features. I wonder whether
Konstantin is confusing v2 vs v3 with use of simple vs. extended query
protocol within v3.
regards,
selects
to avoid getting caught by this accidentally.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
cation that doesn't have to worry about questions like
cross-type comparison semantics; but that's why you don't see such a
feature in current Postgres.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
Tom DalPozzo <t.dalpo...@gmail.com> writes:
> 2017-04-18 22:06 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>:
>> If your session is just sitting, that's not surprising. I think stats
>> updates are only transmitted to the collector at transaction end (and
>> even then,
st sitting, that's not surprising. I think stats
updates are only transmitted to the collector at transaction end (and
even then, only if it's been at least N msec since the last transmission
from the current session).
regards, tom lane
--
Sent via pgsql-general mailing l
REATE VIEW
regression=# create or replace view v1 as select f1, f2, f3 from t1;
CREATE VIEW
So I think your options are (1) explain what you're really doing,
or (2) update.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chan
Paul Jungwirth <p...@illuminatedcomputing.com> writes:
> On 04/10/2017 11:35 AM, Tom Lane wrote:
>> I'm not very keen on recommending that the OP insert an ORDER BY into
>> each aggregate call, because that would cause a separate sort for each
>> aggregate (unless someo
e sort for each
aggregate (unless someone's improved that recently while I wasn't
looking).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
at the two aggregate
functions will see the data in the *same* unspecified order. I think
that's a pretty safe assumption. The server would have to go way
out of its way to do differently, and it doesn't.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
er | 392 | RowExclusiveLock | t
> sales_transaction_header | 19077 | RowExclusiveLock | t
Hm, all those entries are showing granted = t, implying that they are
not blocked. I think you are mis-querying pg_locks or mis-interpreting
the results.
regards, tom lane
--
Sent v
g us about such decisions is many
miles south of abysmal. So you might look at whatever patches
are in the Debian package to see if there's anything touching
pgstat.c's socket-setup logic.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
9.4.
I've just about finished adjusting the patch for the back
branches, and will push in a little bit.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
further back than it was already in use.
regards, tom lane
diff --git a/src/backend/utils/adt/int128.c b/src/backend/utils/adt/int128.c
index ...8bc0663 .
*** a/src/backend/utils/adt/int128.c
--- b/src/backend/utils/adt/int128.c
***
**
to create it in 10. For this project using 10 isn't a problem and I'll
> be doing that.
Interesting. That probably traces back to Emre Hasegeli's work from
last year (commit 77e290682).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
se, maybe src/tools/.
Thoughts?
regards, tom lane
/*-
*
* int128.h
*Roll-our-own 128-bit integer arithmetic.
*
* We make use of the native int128 type if there is one, otherwise
* implem
t find this commit message informative:
https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=9118d03a8
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rid of per-inner-row
visibility checks and some buffer locking overhead, so it cuts the
constant factor some, but the big-O situation is still disastrous.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscripti
ly redundant with the
constraint index.
regards, tom lane
--
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 to sign-extend the partial product terms. The second
attached file is a version that I can't break anymore, though I'm
not quite sure it's bug-free.
regards, tom lane
#include "postgres.h"
/*
* LinearInterval's alternative defeinition for the envir
stuff seems to use the
> functions.
Looking at this now ... why isn't the INT64_AU32 macro just
#define INT64_AU32(i64) ((i64) >> 32)
? The business with subtracting and re-adding 1 seems unnecessary, and it
also creates a risk of overflow with the minimum possible int64 value.
tation is pretty opaque --- why
use the same "operator" for both transformation directions? --- but
don't blame us, blame the SQL spec.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
is allow you to treat an output column name as
something you can re-use in an expression. If you want that, use a
sub-select, viz
SELECT * FROM (SELECT x+y AS z, q FROM ...) ss ORDER BY z+q
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Fri, Mar 31, 2017 at 10:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think the benefit is reduction of user confusion. Admittedly, since
>> Paul is the first person I can remember ever having
Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The argument for not back-patching a bug fix usually boils down to
>> fear of breaking existing applications, but it's hard to see how
>> re
Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes:
> At Thu, 30 Mar 2017 10:57:19 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in
> <2087.1490885...@sss.pgh.pa.us>
>> A possible solution is to manually work in wider-than-64-bit
>> arithmetic, that
Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> In short, it seems like this statement in the docs is correctly describing
>> our code's behavior, but said behavior is wrong and should be changed.
&g
t in HEAD; I'm not sure if the back branches
should also be changed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e extension's
initial script and which had been issued later --- so pg_dump just
assumed they were all of the former kind and didn't dump anything
for extension member objects.
> I am using version 9.5.6.
9.6.x will make this better for you.
regards, tom lane
--
Sent v
Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes:
> At Tue, 21 Mar 2017 07:52:25 -0700, Adrian Klaver <adrian.kla...@aklaver.com>
> wrote in <375c9e5a-960f-942c-913f-55632a1f0...@aklaver.com>
>> On 03/21/2017 07:42 AM, Tom Lane wrote:
>>>
t of the database. You might consider that either a feature or a
bug depending on your use-case, but that's how it works ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ps://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=69f4b9c85
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
by means of failure or
> success to create a judiciously crafted FK).
Aside from that, an FK can easily be used to cause effective
denial-of-service, for example preventing rows from being deleted
within a table, or adding enormous overhead to such a deletion.
regards,
d rows below. I am not sure if it is something to do with
>> upgrade or not.
> So are you using replication slots?
Or prepared transactions? Or maybe you just have a really old open
transaction?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@pos
Jiri Sadek <jiri.sa...@gmail.com> writes:
> On 27.3.2017 15:46, Tom Lane wrote:
>> I think you'll find that 9.6.2 makes this significantly better.
>> https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=48a6592da
> Actually we did all the testing on 9.6.2-1
ou'll find that 9.6.2 makes this significantly better.
https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=48a6592da
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
sn't seem to think
they have any responsibility to give back at all.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ve looked into pg_authid
to find out that the supplied userid wasn't valid.
IOW, the point of the ping functionality is to test whether the server
is up, not whether you have valid login credentials.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-genera
e problem is overflow of the result of interval_cmp_value,
because it's trying to compute
=# select '32618665'::int8 * 30 * 86400 * 100;
ERROR: bigint out of range
It's not immediately obvious how to avoid that while preserving the same
comparison semantics :-(
regards, to
you want to have it up
all the time, as the OP seemingly does, you ought to be running it as
a service.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
g over left and right on the commit you pulled,
then you got a bad version. If all is green on the buildfarm but
it's not working for you, then we'd like to hear details.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
ml#ARRAYS-IO
Personally I tend to write an ARRAY[] construct in preference to
manually adding extra quotes and backslashes to such values.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.po
e changed the default
value of ssl_renegotiation_limit to zero around 9.2.14, and you might
want to set that explicitly in your 9.2.9 server.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscript
ipedia entry. I don't even
have a wikipedia account.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
here:
https://www.postgresql.org/docs/9.2/static/storage.html
and for help in identifying specific files you might like oid2name:
https://www.postgresql.org/docs/9.2/static/oid2name.html
although it's certainly possible to get the same results with manual
queries on the system catalogs.
ip", that's in
a sub-SELECT, where you could just add a join to words_users without
needing any nonstandard DELETE syntax.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Adrian Klaver <adrian.kla...@aklaver.com> writes:
> On 03/13/2017 08:52 AM, Tom Lane wrote:
>> If by "history" you're worried about the server-side statement log, this
>> is merest fantasy: the createuser program is not magic, it just constructs
>> and sends
ecided to get rid of the postgres
database" being one of the unhandled cases.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ou're superuser) you could shut off log_statement
for your session first.
If by "history" you mean ~/.psql_history, you could turn that off (psql -n)
or to protect the password specifically, you could use psql's \password
command.
regards, tom lane
--
Sent
imagine storing as numeric and
having CHECK constraints that cast to string and make those tests,
but I fear trailing zeroes would break it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e-line-for-nolocal@", depending on the switches
it was given. Likewise the various other @something@ bits should
have been changed to something else.
It certainly wasn't working before if it was like this, either.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
a directory
afterwards; there's no reason to change that during a minor-version
upgrade. I'd check the other configuration files in $PGDATA too,
just in case SlackBuilds is fat-fingering them as well.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
John Iliffe <john.ili...@iliffe.ca> writes:
> On Thursday 09 March 2017 12:08:01 Tom Lane wrote:
>> AFAICS, the explanation must be that getaddrinfo() returned two IPv4
>> addresses, one of which got bound successfully and the other not.
>> The bleat is about the non-wor
ar/run/postgres. Evidently that's
not the case.
(I will complain that you're still being absolutely terrible about
reporting error messages precisely. I do not want to see you say again
that "program X complains something". Please *copy and paste the exact
error message* from now on. Ev
John Iliffe <john.ili...@iliffe.ca> writes:
> On Wednesday 08 March 2017 23:35:10 Tom Lane wrote:
>> That isn't proving a lot: as I showed in my example lsof output,
>> Fedora's lsof will map "5432" to "postgres" in the context of an IP
>> port n
That isn't proving a lot: as I showed in my example lsof output, Fedora's
lsof will map "5432" to "postgres" in the context of an IP port number.
(I'm sure there's a way to turn that off, but -n ain't it.)
regards, tom lane
--
Sent via pgs
e root of the problem is
networking misconfiguration on your machine, such that IPv4 doesn't work
at all; given the platform's bias towards IPv6 for loopback, you might
not have noticed otherwise. You might check what results you get from
"ping ::1" vs "ping 127.0.0.1" vs "pin
s to
kill -9 it. Now I am suspicious that you in fact haven't killed any
postmasters, but only removed their pidfiles out from under them, which is
an incredibly dangerous thing to do. Check "ps ax" output to see if any
postgres processes are lurking in background.
elsewhere.
You didn't mention what platform you're on, but the reference to SELinux
makes me think it's probably Red Hat. A bit of digging in RH's support
portal turns up a few mentions of kernel bugs causing unexpected
EADDRNOTAVAIL errors, which matches this symptom ... so how up-to-date
is this
r, integer,
money, timestamp with time zone, timestamp with time zone, timestamp with
time zone) does not exist
I do not think this message corresponds to the sample call you showed us,
because the whole point is that the eleventh parameter wasn't already of
type "money".
a large table the correctly-chosen index will
make an enormous difference.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Rui Pacheco <rui.pach...@gmail.com> writes:
> Is there a way to force the backend to send a PortalSuspended message to
> the front-end?
In your Execute message, request fewer rows than you know the portal will
produce.
regards, tom lane
--
Sent via p
s not
very obvious what's happening.
This is a great example of "select distinct" being used as a band-aid
over a fundamental misunderstanding of SQL. It's good advice to never use
"distinct" unless you know exactly why your query is generating duplicate
rows in the first plac
lect
> count(*) from pg_stat_activity;" but the number is always far from the
> configured max_connections.
You could enable log_connections and log_disconnections.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make cha
ght take
some interest in this ... but nobody is going to spend time guessing
at all the details you didn't supply.
https://www.postgresql.org/docs/current/static/bug-reporting.html
https://wiki.postgresql.org/wiki/Slow_Query_Questions
regards, tom lane
--
Sent via pgsql-general maili
Adrian Klaver <adrian.kla...@aklaver.com> writes:
> On 02/26/2017 08:50 AM, Tom Lane wrote:
>> I'm not entirely sure why the OP feels he needs an index on this
>> expression. If he's willing to restrict the column to have the
>> exact format '-MM-DD', then a regul
sort
the same anyway. Perhaps what's needed is just to add a CHECK
constraint verifying that the column has that format.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s
to an integer". It's not "guess whether it's okay to throw away some
bits to make an integer".
As an example, even if you think it's obvious that it would be okay
to convert that bitstring to "15", would it be all right to convert
x'FFFFF' to "-1" ?
=?utf-8?Q?Fran=C3=A7ois_Beaulieu?= <fr...@tzone.org> writes:
>> On Feb 21, 2017, at 6:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> (The reason it goes into the WAL stream is so that you can have listeners
>> on replication slaves, not for recovery purposes.)
to create more than the minimum number of partitions
you really need.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
reason it goes into the WAL stream is so that you can have listeners
on replication slaves, not for recovery purposes.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
king wired to both). [sorry if Wired is not the correct term, that
> is what I was assigned to do… so I am asking here].
> URL?
https://www.postgresql.org/docs/current/static/protocol.html
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general
g | bigint | | | | plain |
View definition:
SELECT int8_tbl.q1,
int8_tbl.q2,
g.g
FROM int8_tbl
CROSS JOIN LATERAL generate_series(1::bigint, int8_tbl.q1) g(g);
regards, tom lane
--
Sent via pgsql-general mailing list
JOIN condition, so it never
eliminates s rows. Rows not satisfying the condition will be
null-extended instead.
> FROMwords_scores s
> LEFT JOIN words_games g USING(gid)
> WHERE s.uid = 1
In this one, it's part of the top-level WHERE, so it does eliminate s
rows.
t should be sufficient to
compare xmins. Comparing the xmax values would add nothing to that,
except that it would reject if another update had been attempted and
then failed, which seems undesirable.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-
n such cases. I could imagine either behavior being "right" depending on
your application needs.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
se.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
because what you ought to get
in normal cases is
createdb: database creation failed: ERROR: database "testdb" already exists
There may be some corruption in pg_database_datname_index that is allowing
the initial search to not find "testdb" but then the insertion decides
th
ovacuum did you?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
connection's transaction.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
92 | {0.767167}
Ouch. That's saying there's some single value of titleid that accounts
for more than three-quarters of the entries ... does that square with
reality? That'd certainly explain why a hash join goes nuts.
regards, tom lane
--
Sent via pgsql-general mailin
sure your sessions last awhile and execute many queries,
not to decide that the uncached state is the "true" runtime. It's only
representative if you're intentionally shooting yourself in the foot.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsq
back into place makes it start failing
again, then you've narrowed down the problem to something about the
permissions or contents of the data directory itself or the configuration
files therein.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@p
be mighty awkward to use for this
purpose, even if one existed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e desired result.
With SELECT FOR UPDATE, you'd have a tuple lock preventing such race
conditions.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
sql.org/docs/current/static/functions-matching.html
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
roposed remedy would fix it.
It would be useful to see the contents of pg_stats.most_common_freqs
for log_raw.titleid.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
TURNING:
INSERT INTO test (id,name,description)
VALUES (default,'test 1','testing insert')
RETURNING id;
That will get you the generated column's value reliably, and it avoids
one query roundtrip besides.
regards, tom lane
--
Sent via pgsql-general mailing list
t work_mem was only 10MB. I wonder if there's an
integer-overflow problem or something like that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
wondering if you broke
the logging configuration, such that PG tries to write an error log
message but can't, or it's writing it somewhere other than where you
expect.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
rom outside the database, the
contrib/oid2name program might help you.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
re the matching words aren't close together.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
base renames. We're not going back.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
didn't, and in fact didn't evaluate the subexpression at all. But you'd
need a much larger example to demonstrate such a behavior.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
but nobody's gotten
around to writing the necessary interface logic for Postgres.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e dropped and recreated, and that means
that their "initial" privileges are not static system properties.
We might need to fix pg_dump too, but I think these entries in
pg_init_privs should simply not be there.
regards, tom lane
--
Sent via pgsql-general mailing
l.org/gitweb/?p=postgresql.git=commitdiff=9118d03a8
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
301 - 400 of 13723 matches
Mail list logo
