Robert Haas writes:
> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote:
>> The code that recognizes a default expression as being just constant
>> NULL doesn't think this is a constant NULL. In principle it could
>> recognize that, since the cast function is marked st
ng we're going to back-patch.
Given the lack of prior complaints, and the simplicity of the
double-quote workaround, I feel little need to have a back-patchable
fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
e still support for backwards compatibility with versions < 7.3. We
> can fix the immediate problem with something like the attached.
> (a) Should we do that?
That seems like a horrid crock ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@p
x. However, I'm unsure
whether to apply it to released branches ... does anyone think this
might break somebody's application?
regards, tom lane
diff --git a/src/bin/psql/copy.c b/src/bin/psql/copy.c
index 5e69d29b6cbeab56aa0c85e85c3edce46d06efac..ebe5ee9ea551b8
Chris Bandy writes:
> On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane wrote:
>> But AFAICS there is room for implementation dependency in other cases.
>> In the particular cases you show here, PG recognizes some of them as
>> being equivalent to not having a default value, so
Jon Nelson writes:
> On Fri, Jul 1, 2011 at 3:27 PM, Tom Lane wrote:
>> FWIW, I can't reproduce such a failure with current 8.4 branch (nor any
>> other).
> Try adding:
> set enable_mergejoin = false;
Thanks, that did it. I've repaired the symptom exposed
sure worrying about interrupt
response latency is worthwhile.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nt <> as an indexable operator. The odds that that will
ever be of practical use seem negligible, and not at all adequate to
warrant adding extra cycles into mainstream code paths. It's not too
late to rip that out of 9.1, and that's what I think we should do.
"Maksym Boguk" writes:
> But I found I can not stop
> COPY bill.changes (id, cdate, mdate, status, table_name, pk_id, old_row,
> new_row) TO stdout;
> with pg_terminate_backend(procpid) or kill (procpid).
Works for me ...
regards, tom lane
-
fault value, so for efficiency's sake
it converts them to that form. I don't think we're bound to make every
such case work like that, though.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
somewhat related to this issue. I don't recall that
anyone liked his hack though ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
depends on those to work (or rather, not work).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t; "a > 1" predicate in favour of the "a is null" predicate on the
> grounds that "null > 1" in a nulls-last index.
> It looks like a previous revision had the right check, based on the
> logic that x IS NULL is incompatible with any other predicate.
n
strict in pg_proc.h.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Jeff Davis writes:
> http://archives.postgresql.org/pgsql-bugs/2011-06/msg00167.php
It's on my to-look-at list. Your patch looked to me like it would add
extra syscache fetches in typical cases, and I was hoping to find a way
that didn't.
regards, tom lane
it appears that the *actual*
> invoker (current user) is used.
You did not provide any evidence of that. Please show a *complete*
self-contained test case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
gs with a
script in /etc/sysconfig/pgsql/ if you need to change 'em. It's
intentional that those settings win out over postgresql.conf.
I'm not entirely sure that the OP is using the RHEL RPMs, though,
because the fragment he quoted didn't quite match this.
l
is a different situation (because of some files being provided rather
than built on-the-fly) and it doesn't get tested regularly. Anyway,
I've applied fixes and verified that a build works now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bug
sn't display anything (I must
>> force with * to do that).
> i can confirm this
This is allegedly a feature, not a bug, and it's been that way for a
couple releases now: \df with no argument prints only user-defined
functions. I will let those who advocated that behavior defend i
what's different about those two tables: they have no
analyzeable columns. I thinko'd what to do in that situation. Will
fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
pdated correctly.
Hmm ... seems worrisome, all right, but I don't see that happening here.
At least I don't see any indication of it in
pg_stat_all_tables.last_autoanalyze. Are you looking at that, or some
other evidence? Do you have any nondefault settings?
regar
INTO in sub-selects,
and in general I doubt that we ever will, since in most cases the
behavior wouldn't be very well-defined. It might be worth a TODO
to provide a better error message than "syntax error", though.
regards, tom lane
--
Sent via pgsql-bugs
non-Linux platform it seems
possible that this is the mechanism for what's biting you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. On the other hand, it seems to work reliably as-is
on my Linux machine, so this is just speculation at this point.
(BTW, is it really sane to be using ident auth over a "high latency
connection"? That would certainly suggest to me that you could be
getting connections from untrustworthy m
ested regularly, which eliminates various
other theories about PG portability problems.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
http://archives.postgresql.org/pgsql-bugs/2010-04/msg00127.php
Aside from pestering Apple to fix it, there's not much you can do except
install GNU libreadline and link against that instead.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
tuplestore_putvalues() forgot to do so. So data loads
that go through that particular API would miss incrementing the space
counter.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the report!
> $ diff pg_basebackup.c.DIST pg_basebackup.c
BTW, plain diffs are just about useless, since patch can't apply them
safely if the code has changed at all. Please send -c or -u format
diffs in future.
regards, tom lane
--
Sent via pgsql-bugs mailing list
which for extra credit could
go through the pager.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nt environment settings,
and the error message seems reasonably appropriate for that.
Try making LC_CTYPE match the rest.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
he error message) to that trigger issue.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Denis de Bernardy writes:
> Wrapping apparently doesn't want to work in expanded mode...
No, it's not supposed to.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql
'a' to the collection_type_identifier not the
dtd_identifier. As far as I can tell from the spec, dtd_identifier
ought to be the identifier of the element type, while
collection_type_identifier should be a made-up identifier for the array
type. That would make the sample query
Robert Haas writes:
> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
>> It might be that it'd be best just to have both the planner and executor
>> throwing errors on unlogged tables, rather than rejiggering pieces of
>> the planner to sort-of not fail on an unlogged t
n't think the requirements have gone down any ...
> I had in mind for pg_dump to decide to use the non-standard syntax iff
> it was necessary at dump time.
Maybe. I'm concerned about the cost of determining whether it's
necessary ("cost" meaning both "run
throwing errors on unlogged tables, rather than rejiggering pieces of
the planner to sort-of not fail on an unlogged table.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t covers both seqscan
and indexscan accesses.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nvent
strange nonstandard behavior to work around the fact that USING
is fragile *by definition*. Complain to the standards committee
about that.
(Question: would you also have us try to work around the fact that
USING stops working if you rename one of the join columns?)
which FK constraints will be checked.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
D or vice
versa table state changes, you don't want to be testing this in the
parser. It has to be done at plan or execute time.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Greg Stark writes:
> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>> I'm inclined to write this off as "so don't do that". There's nothing
>> that pg_dump can do to make this work: it has to use the USING syntax
>> for the join, and that doe
David Fetter writes:
> On Sat, Jun 04, 2011 at 05:24:22PM -0400, Tom Lane wrote:
>> We could paste a copy of the original's cteList into the rule action,
>> but there are still issues:
>>
>> * If there's more than one rule action, we could end up executi
like RFC says it should".
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
#x27;t mix with CTE queries);
but the second case seems seriously annoying, since there's no way for
someone to write a CTE-containing rule action without risking a
conflict. Ideas anybody?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Dylan Adams" writes:
> If you create a view based on a VALUES statement with an ORDER BY clause,
> the SQL produced by pg_dump can't be loaded back into the database.
I've applied a patch for this. Thanks for the report!
regards, tom lan
Robert Haas writes:
> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
>> Now, if the query doesn't involve any explicit reference to "joinalias.*",
>> we could probably fake it with some ugly thing involving
>> COALESCE(leftcol, rightcol) ... but I don'
"Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Personally my advice is to avoid USING: it wasn't one of the SQL
>>> committee's better ideas.
> There's no query you can write with USING that you can't write in a
> longer
Robert Haas writes:
> On Fri, Jun 3, 2011 at 10:59 AM, Tom Lane wrote:
>> Personally my advice is to avoid USING: it wasn't one of the SQL
>> committee's better ideas.
> I don't understand why we can't just translate the USING into some
> equivalent con
tables used in the
views, and so on.
Personally my advice is to avoid USING: it wasn't one of the SQL
committee's better ideas.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ple, and note that the
lame HOLD_INTERRUPTS hack isn't in the version the OP is running.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
#x27;today'::timestamp"??
> today() is not a builtin function, we can't change it to "select
> today()::timestamp";
You can get that by using date_trunc on the result of now(); or there's
current_date, which is actually SQL-standard unlike these other things.
what
the code looks like now. The subsequent whacking around of the backend
cmsgmem declaration was documented as fixing problems on NetBSD and then
OpenBSD. If it's true as per the libpq comment that only FreeBSD needs
the client-side cmsgmem buffer, this might not have gotten retested.
nch of auth_peer gets compiled...)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
correct anymore. Use CREATE EXTENSION.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
and not the
> next. Here's what I now get on 8.4, 9.0, and 9.1:
> $ pgbench btest1 -n
> setrandom: invalid maximum number 0
That's not valid syntax. Some versions of getopt() take it upon
themselves to rearrange the switch order, some do not ...
reg
breakpoint on the 0xC005 exception in Visual Studio.
AFAIK there isn't any way to exercise the receive functions via psql.
You need a client that will send data as binary parameters. But it's
obvious by inspection of the code that it's broken. Will fix, thanks
for the report!
I wrote:
> Robert Haas writes:
>> On Sun, May 15, 2011 at 5:02 PM, Tom Lane wrote:
>>> Robert Haas writes:
>>>> On Thu, May 12, 2011 at 6:20 PM, Tom Lane wrote:
>>>>> One possibility is to start showing "default" when the AC
ld be more user-friendly, if we can
do it without too much pain.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas writes:
> On Sun, May 15, 2011 at 5:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, May 12, 2011 at 6:20 PM, Tom Lane wrote:
>>>> One possibility is to start showing "default" when the ACL is null,
>>>> which would be
float values is going to bite you
sooner or later, unless you know exactly what you're doing.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Martin A. Brooks" writes:
> On Mon, May 23, 2011 19:02, Tom Lane wrote:
>> ISTM that changing interval's output formatting would create far too
>> many problems to be justifiable for such a purely cosmetic issue.
> I almost entirely agree with you except
&
e idea of leaving it as-is, either.
ISTM that changing interval's output formatting would create far too
many problems to be justifiable for such a purely cosmetic issue.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make cha
ww.ergora.eu/data/postgresql/crashdump.sql.lzma I get unexpected
> results:
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
unhandled-overflow problem...
Do you want to take care of this one?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
newtmp = tmp * 10 + (*ptr++ - '0');
if ((newtmp / 10) != tmp) /* overflow? */
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas writes:
> On Thu, May 12, 2011 at 6:20 PM, Tom Lane wrote:
>> One possibility is to start showing "default" when the ACL is null,
>> which would be quite easy to implement:
>>
>>COALESCE(array_to_string(c.relacl, E'\n'), '
d* tell
the difference between default privileges and no privileges.
The precedent of previous versions makes it more plausible that we
should print '{}' for no privileges, but I'm still not quite convinced.
Anybody else have an opinion?
regards, tom lan
me snapshot that will be used at execution" case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
big a change. Or we could take the opposite
tack of changing the display in the no-privileges case; but I don't
see a similarly compact way to do that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
all
obvious whether we ought to try to change this in released branches.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
fix list --- in fact there was a patch submitted for it last year,
although it got returned for rework and we've not seen it again yet.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
and you can use timezone
abbreviations, not just whether 'infinity' crashes.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas writes:
> On Wed, May 4, 2011 at 4:39 PM, Tom Lane wrote:
>> "Daniel Grace" writes:
>>> ALTER ROLE foo WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN
>>> NOREPLICATION VALID UNTIL 'infinity';
>> Hmm, cannot dupli
tions, and
COLLATE is one of the ones that it doesn't support.
(The actual technical reason for this is that COLLATE turns the argument
into a general expression, not something we can special-case. You would
get the same error from writing "1 COLLATE something" anyplace else.)
ial
example suggested. I've been able to duplicate the error and confirm
that the behavior changed in 9.0, but have not yet tracked down why.
More news as it develops ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make c
t; --- well, you can
declare it that way, but the database just ignores the length modifier.
And BPCHAR is just the internal name for CHAR(n), so it should certainly
have matched.
Could we see the *exact* function declaration, the exact SQL you issued,
and the exact error message, rather than ambiguou
s 'abcd' where the type is character(4).
> However, if I do the cast in the FROM portion of the query such as this:
> SELECT
> data
> FROM
> CAST('abcd' AS CHAR(4)) AS data
> then I am returned 'abcd' and the type is bpchar.
What exactly ar
ed before the first is
executed. If we were reimplementing SQL functions then it'd make sense
to try to do something about that at the same time.
None of this is on the TODO list, but I'll go fix that momentarily.
regards, tom lane
--
Sent via pgsql-bugs mailing li
Bruce Momjian writes:
> Tom Lane wrote:
>> Hmm ... considering that's the first thing in the release notes, I'm
>> surprised Martin missed it. Maybe he was looking for something
>> mentioning backslashes ... should we add a bit that specifically says
>> that
;s the first thing in the release notes, I'm
surprised Martin missed it. Maybe he was looking for something
mentioning backslashes ... should we add a bit that specifically says
that backslashes are now no-ops by default?
regards, tom lane
--
Sent via pgsql-bugs mail
Martin Pitt writes:
> Tom Lane [2011-05-10 10:03 -0400]:
>> [ raised eyebrow... ] What platform? This seems to point towards "C"
>> locale not doing what it is supposed to ...
> After your comment I checked locales on my system, and for some reason
> I had an /u
ystem's timezone)'
Anyone have a better idea?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
sed eyebrow... ] What platform? This seems to point towards "C"
locale not doing what it is supposed to ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
eful without them.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
eed it appears
to do so in all the cases on the Unix side of the fence. However,
someone chose to code these Windows-specific messages as direct
write_eventlog calls instead of going through print_msg, which means
that -s doesn't silence them. So possibly the OP is right that this is
a bug a
://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
pg_restore -l" prints the
source database name in two different places for me.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
as bollixing relfrozenxid values. But that makes at least
two reports from people who (claimed they) didn't use pg_upgrade.
So maybe there is something else going on. I see no way to investigate
on the strength of the available evidence though ...
regards, tom lane
--
Se
elp.
regression=# select 1/0; select 2;
ERROR: division by zero
?column?
--
2
(1 row)
regression=# \set ON_ERROR_STOP 1
regression=# select 1/0; select 2;
ERROR: division by zero
regression=#
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsq
database ...
Well, if the docs say that they shouldn't. When you use -C, the
database named by -d is just the one where pg_restore initially connects
to issue the CREATE DATABASE command. Please specify where you think
the documentation is telling you something else.
x';
> CREATE ROLE foo;
> ALTER ROLE foo WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN
> NOREPLICATION VALID UNTIL 'infinity';
> The final statement causes postmaster to crash.
Hmm, cannot duplicate this here ... can anyone else? Windows-specific
issue perhaps?
n with stale snapshots, so it's not super credible, but ...
I'm inclined to think that the xmin=xmax test is just too cute and
should be dropped altogether, ie removing the first if-block quoted
above would fix the problem. Anyone see a better answer?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bruce Momjian writes:
> Tom Lane wrote:
>> It already is documented. See
>> http://developer.postgresql.org/pgdocs/postgres/datatype-datetime.html#DATATYPE-TIMEZONES
>> specifically the point that POSIX zone names have the opposite sign
>> convention from ISO-8601.
&
The great thing about standards is there are so many to choose from ;-)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
- "-8388607 TB"
Yeah, that's a bug. Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas writes:
> On Wed, Apr 20, 2011 at 7:13 PM, Tom Lane wrote:
>> I have stated previously my opinion that this is a misconceived feature,
>> and it's now apparent that the implementation is as poorly thought
>> through as the definition. My recommendati
s (because
indexes built at bootstrap time aren't included in pg_depend) --- not
sure if that is something SQLAlchemy cares about.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t exactly do you think is required?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
#x27;re trying to accomplish and how it might be done
in a more bulletproof fashion. The actual names of the columns of an
index are an implementation detail that shouldn't be relied on.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
this to the TODO Wiki page with
> a reference to Tom's description of how it should be implemented.
I think there might be something related there already, but if not,
feel free to add it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
1001 - 1100 of 7582 matches
Mail list logo
