ms seeing a stale value looks plain
wrong (and will cause no end of questions from people asking why lag
is still showing when their system isn't doing anything).
I suggest the documentation of these columns needs to be extended to mention
that they will be NULL if no lag was measured recentl
Hi
On 12/02/2016 11:01 PM, Robert Haas wrote:
On Wed, Nov 30, 2016 at 8:45 PM, Ian Barwick
wrote:
Small doc patch to clarify how much of the query text is show in
pg_stat_statements
and a link to the relevant GUC.
This patch improves the pg_stat_activity documentation, not the
Hi
Small doc patch to clarify how much of the query text is show in
pg_stat_statements
and a link to the relevant GUC.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/
time to review this!
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ommitfest.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index a62ffe6..a87b483
*** a/src/bin/psql
On 05/04/16 10:24, Peter Eisentraut wrote:
> On 03/30/2016 09:15 PM, Ian Barwick wrote:
>> Currently pg_create_physical_replication_slot() may refer to
>> the deprecated wal_level setting "archive":
>
> I have fixed this in the most direct way, since there was some
On 16/04/01 8:15, Michael Paquier wrote:
> On Thu, Mar 31, 2016 at 11:18 PM, Alvaro Herrera
> wrote:
>> Andres Freund wrote:
>>> On 2016-03-31 10:15:21 +0900, Ian Barwick wrote:
>>
>>>> Patch changes the error message to:
>>>>
>>>&g
ouple of places, i.e.
"wal_level must be set to "replica" or "logical" at server start."
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/r
rant.com
The linked thread might provide more insights into the issues surrounding
this proposal.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgs
vacuum (9.5)
Attached patches (for 9.4 and 9.5/HEAD) update the description to make
clear that it now does a bit more than just execute a single command.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Serv
I'm not completely in
>>> love with the proposed third column in the table it adds, but otherwise
>>> is factually correct as far as I can tell.
>>
>> I'm not clear whether you are asking for help with this, or ...?
>
> I enlisted the help of Ian Barwic
On 29/04/15 09:12, Bruce Momjian wrote:
> On Fri, Feb 6, 2015 at 08:25:42AM -0500, Robert Haas wrote:
>> On Thu, Feb 5, 2015 at 10:21 PM, Ian Barwick wrote:
>>> I stumbled on what appears to be inconsistent handling of double slashes
>>> in tablespace paths when u
is not canonicalized in the same way
it is pretty much everywhere else (including in "CREATE TABLESPACE").
The attached patch adds the missing canonicalization; I can't see any
reason not to do this. Thoughts?
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQu
On 04/02/15 19:02, Fujii Masao wrote:
> On Wed, Feb 4, 2015 at 5:27 PM, Ian Barwick wrote:
>> Hi
>>
>> A superfluous '/' in an xref tag is producing an unintended '>'
>> in the "Warning" box on this page:
>>
>>
>>
Hi
A superfluous '/' in an xref tag is producing an unintended '>'
in the "Warning" box on this page:
http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuad
On 15/01/01 1:07, Robert Haas wrote:
> On Sun, Dec 28, 2014 at 7:44 PM, Ian Barwick wrote:
>> Currently tab completion for 'COMMENT ON {object} foo IS' will result in the
>> 'IS'
>> being duplicated up to two times; not a world-shattering issue I know, b
Hi
Currently tab completion for 'COMMENT ON {object} foo IS' will result in the
'IS'
being duplicated up to two times; not a world-shattering issue I know, but the
fix is trivial and I stumble over it often enough to for it to mildly annoy me.
Patch attached.
Regards
On 14/12/07 12:43, Bruce Momjian wrote:
> On Tue, Dec 2, 2014 at 03:13:07PM -0300, Alvaro Herrera wrote:
>> Robert Haas wrote:
>>> On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick wrote:
>>
>>>> A simple schedule to demonstrate this is available; execute from
This fixes a missing space here:
http://www.postgresql.org/docs/devel/static/wal-reliability.html
(present in 9.3 onwards).
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc
--schedule=./schedule_ddl_deparse_demo
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/test/regress/expected/.gitignore b/src/test/regress/expected/.gitignore
index 93c56c8..2eeaf57
On 28/11/14 00:02, Andrew Dunstan wrote:
On 11/27/2014 04:12 AM, Ian Barwick wrote:
Hi
pg_regress provides the command line option "--dbname",
which is described in the help output thusly:
--dbname=DBuse database DB (default "regression")
It does however a
S only ever uses the first database in the list.
Is there a reason for this I'm not seeing?
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 14/11/21 22:10, Heikki Linnakangas wrote:
> On 11/21/2014 06:23 AM, Ian Barwick wrote:
>> I thought it might be useful to add a few words at the top
>> of 'src/test/regress/regress.c' to explain what it does and
>> to help differentiate it from 'pg_
I thought it might be useful to add a few words at the top
of 'src/test/regress/regress.c' to explain what it does and
to help differentiate it from 'pg_regress.c' and
'pg_regress_main.c'.
Regards
Ian Barwick
--
Ian Barwick http://ww
On 10/11/14 22:20, Robert Haas wrote:
On Sun, Nov 9, 2014 at 6:13 PM, Ian Barwick wrote:
Attached is a mighty trivial patch to extend psql tab completion
for \c / \connect to generate a list of role names, as lack thereof
was annoying me recently and I can't see any downside to doing
t but will happily do so if appropriate.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 886188c..56d
f having time before November
> given the other things I'm involved in right now and pgConf.eu happening
> in a few weeks.
Thanks :) We're updating pgAudit for submission this for the upcoming
commitfest,
it will be added within the next few days.
Regards
Ian Barwick
--
Ian Barwick
27;s just my subjective
opinion (possibly coloured by the particular implementation) and not
necessarily a pro/contra argument ;).
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-ha
S" clause:
RETURNING PRIMARY KEY [ IF EXISTS ]
which would be easy enough to implement.
Thoughts?
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing
On 02/07/14 15:16, Ian Barwick wrote:
On 14/07/01 23:13, Robert Haas wrote:
On Tue, Jul 1, 2014 at 8:00 AM, Rushabh Lathia wrote:
.) In map_primary_key_to_list() patch using INDEX_ATTR_BITMAP_IDENTITY_KEY
bitmap to get the keycols. In IndexAttrBitmapKind there is also
INDEX_ATTR_BITMAP_KEY
ly, that depends on how REPLICA IDENTITY is set. IOW, you can't
> assume that will give you the primary key.
Damn, fooled by the name. Thanks for the info; I'll rework the patch
accordingly.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
Po
with the expanded primary key columns, or something
equally messy).
On the other hand, it should be fairly straightforward to handle a list of
keywords
for expansion (e.g. "RETURNING PRIMARY KEY, UNIQUE KEYS, SEQUENCE VALUES")
should
the need arise.
Regards
Ian Barwick
--
Ian B
of the others, but still more than nothing.
https://www.mysql.com/products/enterprise/audit.html
https://mariadb.com/kb/en/about-the-mariadb-audit-plugin/
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
On 25/06/14 16:04, Ian Barwick wrote:
Hi
On 14/06/25 15:13, Rushabh Lathia wrote:
Hello All,
I assigned my self as reviewer of the patch. I gone through the
mail chain discussion and in that question has been raised about
the feature and its implementation, so would like to know what is
the
us of this project/patch.
>
> Regards,
I'll be submitting a revised version of this patch very shortly.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-ha
"; how
about having these listed only once "pg_" is entered, i.e.
"SET search_path TO pg_"?
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"log_temp_files", "log_disconnections" etc.
- It might be an idea to add a cross-reference to this parameter from
the "Streaming Replication Protocol" page:
http://www.postgresql.org/docs/devel/static/protocol-replication.html
Regards
Ian Barwick
--
Ian Barwick
On 19/06/14 12:35, Tom Lane wrote:
Peter Geoghegan writes:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote:
Interesting, I'll take a look later.
I'm pretty suspicious of incompatibilities that may exist between the
two sets of OS collations involved here. We aren't ve
On 19/06/14 12:30, Peter Geoghegan wrote:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote:
Interesting, I'll take a look later.
I'm pretty suspicious of incompatibilities that may exist between the
two sets of OS collations involved here. We aren't very clear on the
exten
On 19/06/14 11:58, Peter Geoghegan wrote:
On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick wrote:
I've just run into an index issue on 9.5 HEAD on a slave (master and slave
both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details
below (I have only found one index on the slave
_id | login
-+---
1 | admin
(1 row)
tgg_current=> \d tgg_user_login_key
Index "epp.tgg_user_login_key"
Column | Type | Definition
+---+----
login | character va
On 14/06/18 7:51, Andreas Karlsson wrote:
> On 06/17/2014 01:36 PM, Ian Barwick wrote:
>> One issue - the table's internal triggers will also be listed. which can
>> result in
>> something like this:
>>
>> This is a bit of an extreme case, but I don
er_a_1916421" "RI_ConstraintTrigger_c_1916329"
ts_vector_update
This is a bit of an extreme case, but I don't think manually manipulating
internal triggers (which can only be done as a superuser) is a common enough
operation to justify their inclusion. I suggest adding
On 14/06/17 11:57, Peter Geoghegan wrote:
> On Mon, Jun 16, 2014 at 7:09 PM, Ian Barwick wrote:
>> Howver in this particular use case, as long as it doesn't produce false
>> positives (I haven't looked at the patch) I don't think it would cause
>> any probl
On 14/06/17 9:53, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Jun 17, 2014 at 9:30 AM, Ian Barwick wrote:
>>> From what I've seen in the wild in Japan, Roman/ASCII characters are
>>> widely used for object/attribute names, as generally it's much l
ethods, dealing with different
encodings etc. The only place where I've seen Japanese characters widely
used is in tutorials, examples etc. However that's only my personal
observation for one particular non-Roman language.
Regards
Ian Barwick
--
Ian Barwick http://www.2
text AS $$
> DECLARE
> local_a, local_b, local_c text := 'a1';
> BEGIN
> return local_a || local_b || local_c;
> end;
> $$ LANGUAGE plpgsql;
Please submit this patch to the current commitfest:
https://commitfest.postgresql.org/action/commitfest_view?id=22
Rega
On 14/06/12 20:58, Jochem van Dieten wrote:
> On Thu, Jun 12, 2014 at 12:25 PM, Ian Barwick wrote:
>
> On 14/06/12 18:46, Jochem van Dieten wrote:
> > I haven't checked the code, but I am hoping it will help with the
> problem
> > where a RETURNING * is
side
of the scope of this particular patch (which proposes additional server-side
syntax intended to make RETURNING * operations more efficient for
certain use cases, but which is in itself not a JDBC change).
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com
On 09/06/14 14:47, David G Johnston wrote:
Ian Barwick wrote
Hi,
The JDBC API provides the getGeneratedKeys() method as a way of retrieving
primary key values without the need to explicitly specify the primary key
column(s). This is a widely-used feature, however the implementation has
ady locked by that point and the primary key cannot
change.
A patch is attached which implements this, and will be added to the next
commitfest.
A separate patch will be submitted to the JDBC project. Example usage shown
below.
Regards
I
, and potentially logging to a table
(possibly via a bgworker process). Currently output is simply
emitted to the server log via ereport().
2. To implement per-object auditing configuration, it would be nice to use
extensible reloptions (or an equivalent mechanism)
Details such as output
ay home
from last year's PgCon (PgEcons made a presentation there:
http://www.pgcon.org/2013/schedule/events/556.en.html ) - it was a long flight
- but
didn't have any
particular incentive to finish it.
It might make a nice JPUG project for members who want to practise their
English.
On 10/04/14 00:23, Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:27 AM, Ian Barwick wrote:
On 08/04/14 18:22, Ian Barwick wrote:
As it was kind of annoying not to have this when playing around with
event triggers.
This also tightens up the existing tab completion for ALTER TRIGGER,
which
On 08/04/14 18:22, Ian Barwick wrote:
As it was kind of annoying not to have this when playing around with
event triggers.
This also tightens up the existing tab completion for ALTER TRIGGER,
which contained redundant code for table name completion, and which was
also causing a spurious "R
is context:
CREATE EVENT TRIGGER foo ON {event} ^I
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index 6e
Just a single missing 's'.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index 6e2fbda..b5807f3
***
OUS_TRANSACTION", the space is presumably a typo.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
in current CVS so was fixed by Tom.
Thanks for the update, I can confirm the issue no longer occurs in
beta2.
Regards
Ian Barwick
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/5/10 Ian Barwick :
> SELECT ov.object_id
> FROM object_version ov
> WHERE ov.object_id = 1
> AND ov.version ='0
> AND ov.object_status_id = (
> SELECT MAX(ov1.object_status_id)
> FROM object_version ov1
> WHERE ov1.object_id=ov.objec
Hi
2010/5/10 Tom Lane :
> Ian Barwick writes:
>> 2010/5/9 David Fetter :
>>> A self-contained way to reproduce this, ideally small, would be
>>> fantastic :)
>
> s/fantastic/absolutely required to do anything with this report/
Yes, I appreciate that :) I
2010/5/9 David Fetter :
> On Sun, May 09, 2010 at 05:48:27PM +0900, Ian Barwick wrote:
>> Hi
>>
>> I've just compiled the 9.0 beta1 source tarball and am testing my
>> custom application against it (which has been running on PostgreSQL
>> since 7.3 or so).
&g
stgreSQL 9.0beta1 on i686-pc-linux-gnu, compiled by GCC gcc (Ubuntu
4.3.2-1ubuntu12) 4.3.2, 32-bit
Ubuntu 8.10 running on a "VIA C7-M" Processor (netbook).
Regards
Ian Barwick
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
://archives.postgresql.org/pgsql-general/2010-03/msg00362.php
I imagine it has some potential as a 'gotcha', as "name" is hardly an
uncommon column name, but it's not an issue which can easily
researched...
Ian Barwick
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2009/4/19 Tom Lane
> Heikki Linnakangas writes:
> > Ian Barwick wrote:
> >> Note I'm not sure whether this is a bug, or whether the assumption
> >> made for the original query (that the row order returned by the
> >> subquery would be carri
sumption
made for the original query (that the row order returned by the
subquery would be carried over to the main part of the query) is
incorrect but just happened to work as expected pre-8.4.
[*] tested on:
- Ubuntu 8.10 running on VIA C7-M
- OS X 10.5 running on Intel Core Duo
Regards
I
MySQL, Msql and Oracle, has
"Postgres" rather than "PostgreSQL" (though there are only two
modules in it, one of which dates from 1998,
see http://cpan.org/modules/by-module/Postgres/ ).
Ian Barwick
---(end of broadcast)---
T
een similar behaviour to this (PostgreSQL processes exiting
"abnormally", index corruption with duplicate primary keys) on servers
with defective RAM chips.
Ian Barwick
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignor
test=> \p
SELECT
'Hello World';
test=>
Ian Barwick
---(end of broadcast)---
TIP 8: explain analyze is your friend
be related to the BDB
> backend that it uses.
Aha, glad I'm not the only one. Version 1.1 has a flat-file based
backend which is not prone to BDB-permission-related problems, see:
http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 .
It's only been around a few mon
vial issue, but
seeing the word "ROLLBACK" when a commit, or at least a non-operation
were expected, can do nasty things to one's blood pressure.
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Tue, 26 Oct 2004 21:42:19 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Ian Barwick wrote:
>
>
> > just wondering:
> >
> > test=> select version();
> >
begin;
BEGIN
test=> commit;
COMMIT
test=> commit;
WARNING: there is no transaction in progress
ROLLBACK
Is there any reason ROLLBACK and not COMMIT is echoed here?
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Mon, 26 Jul 2004 16:32:33 -0700 (PDT), Stephan Szabo
<[EMAIL PROTECTED]> wrote:
> On Tue, 27 Jul 2004, Ian Barwick wrote:
>
> > Apologies if this has been covered previously.
> >
> > Given a statement like this:
> > SELECT * FROM foo WHERE id IN (SELECT i
On Tue, 27 Jul 2004 01:33:44 +0200, Andreas Joseph Krogh
<[EMAIL PROTECTED]> wrote:
> On Tuesday 27 July 2004 01:15, Ian Barwick wrote:
> > Apologies if this has been covered previously.
> >
> > Given a statement like this:
> > SELECT * FROM foo WHERE id IN
0)
(4 rows)
test=> SELECT id FROM bar;
ERROR: column "id" does not exist
test=> SELECT * FROM foo WHERE id IN (SELECT bar.id FROM bar);
ERROR: column bar.id does not exist
test=> ALTER TABLE bar RENAME foo_id TO id;
ALTER TABLE
test=> SELECT * FROM foo WHERE id IN (SELECT
though which I can't recall
offhand. I'll try and write it up next time I got through the process.
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
in
a schema of their own so explicitly addressing them would
work equally well too).
> then he'd not have a
> problem with the availability of tab completion for system catalogs.
I'm sure I can live with that (one more character), at least until I finish
the br
ginning with p in the search path which I access with tab
expansion frequently and I'm sure it would annoy me intensely if I got all the
system tables as well every time.
Mind you that's only my personal preference, I thought it might be unpopular
but as no one has commented since... I can s
On Thursday 21 August 2003 11:15, Shridhar Daithankar wrote:
> On 21 Aug 2003 at 0:22, Ian Barwick wrote:
> > * DDL
> > - Data definition language (table creation statements etc.) in MySQL
> > are not transaction based and cannot be rolled back.
>
> Just wonderin
gh as I have little experience and virtually no docs I might
be missing something).
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
urry.
This section is referring to substitutions in psql's own meta commands,
not SQL statements, e.g. this:
\echo '\0xe2\0x82\0xac'
will display the Euro sign (assuming your terminal can print it).
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
urry.
This section is referring to substitutions in psql's own meta commands,
not SQL statements, e.g. this:
\echo '\0xe2\0x82\0xac'
will display the Euro sign (assuming your terminal can print it).
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)
On Sunday 23 February 2003 20:52, Dave Page wrote:
> > -Original Message-
> > From: Ian Barwick [mailto:[EMAIL PROTECTED]
> >
> > Would it be possible to modify the new docs to provide
> > similar functionality? E.g. something like
>
> http://www.
do this (though I have no idea
of what would be involved ;-).
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
this is how \d currently behaves and IMHO is intuitive.
\d should of course operate on schema names too, to enable
completion of relation names not in the search path; tentative
patch will follow.
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
...what I meant is that after entering \d, TAB will produce a list of tables,
but \di does not produce a list of indexes, same for \dv etc. I see
no particular reason why this is so and can provide patches
if relevant.
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast
kwards
compatibilty to pre 7.3 clients?
- pg_catalog.pg_table_is_visible() works on non-table relations
as well, right?
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send &qu
ostgreSQL,
> > and it is _threaded_:
> >
> > http://osb.sra.co.jp/PowerGres/
>
> Is there an English translation of the site so one who doesn't speak or
> write Japanese can try it out?
Can't see one, but here is a summarized translation of the relevant
parts as
p and start the server in the same way as for the binary Windows
distribution. *Note Windows prepare environment::.
--QUOTE END--
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ied column length. This makes some operations, particularly
comparisions, appear to return unexpected results. For example, if you
insert the string 'hello' (5 characters) into a column defined as CHAR(8) it
will become 'hello ' (8 characters) and simple comparisions with the
orig
en mentioned later. I also added a specific mention of
> the trailing spaces issue. Patch attached.
Err, from the patch:
"CHAR(n) stores trailing spaces, while VARCHAR(n) trims them."
Surely this should read something like:
"CHAR(n) automatically pads st
On Wednesday 08 January 2003 13:02, Alexander M. Pravking wrote:
> On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
> > > Hi,
> > >
> > > Is there any way of making the
nt...
Not that I know of, but you can use \e to edit the query in your
favourite editor.
Ian Barwick
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Hi
building on FreeBSD 4.7-RELEASE; diffs attached.
Seems to be a difference between 0 and -0. Is this anything to worry about?
Ian Barwick
[EMAIL PROTECTED]
regression.diffs.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP
(no followup to [EMAIL PROTECTED], getting a little OT there)
(B
(BOn Tuesday 10 December 2002 16:54, Lee Kindness wrote:
(B> Ian Barwick writes:
(B> > Something along the lines of
(B> > char *PQversion(const PGconn *conn) ?
(B>
(B> Probably:
(B>
(B> int P
(B(crossposting to hackers)
(B
(BOn Tuesday 10 December 2002 00:47, Tom Lane wrote:
(B> In the next protocol version update (hopefully 7.4) I would like to see
(B> the basic version string (eg, "7.3.1" or "7.4devel") delivered to the
(B> client automatically during connection startup and the
On Friday 06 December 2002 20:50, Tom Lane wrote:
(B> Ian Barwick <[EMAIL PROTECTED]> writes:
(B> > ERROR: ExecEvalExpr: unknown expression type 108
(B>
(B> This is fixed as of yesterday --- see thread on (I think) pgsql-general
(B> for the patch.
(B
(BMany thanks
work in 7.1.3 with no
apparent problems.
Question: what does "unknown expression type 108" mean and
why should it suddenly occur in 7.3? A bit of Googling
reveals the same message occurs when using subselects
in constraints, but that doesn't seem related to this case.
Ian Barwick
[
On Thursday 28 November 2002 00:18, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Ian Barwick writes:
> >> "Casting integers to boolean (for example, 0::bool) is no longer
> >> allowed, use '0'::bool instead".
> &g
1 - 100 of 117 matches
Mail list logo
