On 8/13/2013 8:34 PM, Robert James wrote:
I'm confused: What's the difference between
col LIKE 'foo%'
and
col LIKE f1 || '%'
?
Either way, it's anchored to the beginning of the string.
the first one can be analyzed by the planner, the latter would be much
harder to pre-figure.
--
jo
Hi all,
It seems like it isn't possible to perform a wildcard LIKE evaluation
against array objects. Is this a bug, or just unsupported?
See the queries in bold, that I would have expected to return a value.
Postgres 9.1.9
=# create temp table ids (id varchar(12)[]);
CREATE TABLE
Time: 185.516
Hello
http://postgres.cz/wiki/PostgreSQL_SQL_Tricks#LIKE_to_list_of_patterns
Regards
Pavel Stehule
2013/8/14 Tim Kane
> Hi all,
>
> It seems like it isn't possible to perform a wildcard LIKE evaluation
> against array objects. Is this a bug, or just unsupported?
>
>
> See the queries in bold
Hi all,
We are upgrading our mediation product from postgres 8.1 to postgres 9.1
Can you please suggest some test cases or some issues which may hamper us?
Regards
Tarkeshwar
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://ww
M Tarkeshwar Rao wrote:
> We are upgrading our mediation product from postgres 8.1 to postgres 9.1
>
> Can you please suggest some test cases or some issues which may hamper us?
This is the first thing that comes to mind:
http://petereisentraut.blogspot.co.at/2008/03/readding-implicit-casts-in-p
Hi guys,
I am looking for a way to get list of supported types in Postgres
together with information whether type can have optional size (like
varchar for example), whether it can have precision (like decimal for
example), and whether it can come as value of sequence (like all integer
types f
I'm having an interesting issue with PGSQL. It seems that I'm
experiencing timeouts at various times. The servers are not busy and
have plenty of resources. The databases are ~50GB in size, the systems
typically have 8-12GB physical RAM, and the connections are low (less
than 15 at an
Robert James wrote:
> I have a view which is very slow to computer, but doesn't change often.
>
> I'd like to materialize it. I thought I'd do a simple poor man's
> materialize by:
>
> 1) ALTER VIEW myview RENAME to _myview
> 2) SELECT * INTO myview FROM _myview
>
> The only problem is that all m
Robert James wrote:
> I'm confused: What's the difference between
> col LIKE 'foo%'
> and
> col LIKE f1 || '%'
> ?
The planner knows that 'foo%' doesn't start with a wildcard.
> Either way, it's anchored to the beginning of the string.
Not necessarily.
--
Kevin Grittner
EDB: http://www.e
On 08/14/2013 05:50 AM, coutinhovi...@gmail.com wrote:
Thank you Sr.,
I'll try to see who can help me. I can't access postgres server and create data
base without stack builder application installed.
You might want to try the EnterpriseDB forums:
http://forums.enterprisedb.com/forums/list.p
"bweish...@charter.net" wrote:
> I'm having an interesting issue with PGSQL. It seems that I'm
> experiencing timeouts at various times. The servers are not
> busy and have plenty of resources. The databases are ~50GB in
> size, the systems typically have 8-12GB physical RAM, and the
> conne
All your view and function creation statements should be in scripts that
you maintain as a kind of best practice. If you've done that, then you can
simply drop/cascade the view you're replacing after you renamed it and then
rebuild the rest of them.
I actually go one step further and put the view
Hello
I'm having an interesting issue with PGSQL. It seems that I'm
experiencing timeouts at various times. The servers are not busy and have
plenty of resources. The databases are ~50GB in size, the systems
typically have 8-12GB physical RAM, and the connections are low (less than
15 at a
Thank you Sr.,
I'll try to see who can help me. I can't access postgres server and create data
base without stack builder application installed.
Thank you again for your support
Thodi Viola
--Original Message--
From: Adrian Klaver
To: Thodi Viola
Cc: pgsql-general@postgresql.org
Cc
Thanks Pavel,
Unless I'm being bleary eyed and not quite grasping it... I'm not sure
that answers my question.
I'm using a single LIKE clause against an array parameter, rather than
multiple LIKE clauses against a single parameter.
It seems I'm so far stuck with a FOREACH style traversal within
Consider the following SQL:
---
CREATE TABLE t1(m VARCHAR(4));
INSERT INTO t1 VALUES('az');
INSERT INTO t1 VALUES('by');
INSERT INTO t1 VALUES('cx');
SELECT '1', substr(m,2) AS m
FROM t1
ORDER BY m;
SELECT '2', substr(m,2) AS m
FROM t1
ORDER
Tim Kane wrote:
> I'm using a single LIKE clause against an array parameter, rather
> than multiple LIKE clauses against a single parameter.
The problem is that you have the arguments to the LIKE parameter
reversed with the attempts you show. Try something like this:
select * from ids
where
On Wed, Aug 14, 2013 at 12:01 PM, Richard Hipp wrote:
>
> Consider the following SQL:
>
> ---
> CREATE TABLE t1(m VARCHAR(4));
> INSERT INTO t1 VALUES('az');
> INSERT INTO t1 VALUES('by');
> INSERT INTO t1 VALUES('cx');
>
> SELECT '1', substr(m,2) AS
On Wed, Aug 14, 2013 at 2:28 PM, Scott Marlowe wrote:
> On Wed, Aug 14, 2013 at 12:01 PM, Richard Hipp wrote:
>
> substr(m,2) as m
>
> is bad form. Always use a new and unique alias, like m1. How does this
> work:
>
> SELECT '2', substr(m,2) AS m1
> FROM t1
> ORDER BY lower(m1);
>
Tnx. I th
On Wed, Aug 14, 2013 at 12:31 PM, Richard Hipp wrote:
>
>
> On Wed, Aug 14, 2013 at 2:28 PM, Scott Marlowe
> wrote:
>>
>> On Wed, Aug 14, 2013 at 12:01 PM, Richard Hipp wrote:
>>
>> substr(m,2) as m
>>
>> is bad form. Always use a new and unique alias, like m1. How does this
>> work:
>>
>> SELE
Richard Hipp writes:
> There are, of course, many ways to resolve the ambiguity (such as using a
> unique label for the result column, or by saying "t1.m" instead of just "m"
> when you mean the column of the table). But that is not really the point
> here. The question is, how should symbolic n
On Wed, Aug 14, 2013 at 2:56 PM, Tom Lane wrote:
>
> Our interpretation is that a bare column name ("ORDER BY foo") is resolved
> first as an output-column label, or failing that as an input-column name.
> However, as soon as you embed a name in an expression, it will be treated
> *only* as an in
On Wed, 2013-08-14 at 14:01 -0400, Richard Hipp wrote:
> CREATE TABLE t1(m VARCHAR(4));
> INSERT INTO t1 VALUES('az');
> INSERT INTO t1 VALUES('by');
> INSERT INTO t1 VALUES('cx');
>
> SELECT '1', substr(m,2) AS m
> FROM t1
> ORDER BY m;
>
> SELECT '2', substr(m,2) AS m
> FROM t1
> ORDER
Richard Hipp writes:
> Just to be clear, you intend that a COLLATE clause in the ORDER BY is
> treated as an expression, right?
Yeah, that is the current behavior, although I think that it probably fell
out rather than being consciously thought about. Arguably it's the wrong
thing, because it lo
On Wed, Aug 14, 2013 at 02:17:26PM +0200, Ivan Radovanovic wrote:
> Hi guys,
>
> I am looking for a way to get list of supported types in Postgres
> together with information whether type can have optional size (like
> varchar for example), whether it can have precision (like decimal
> for example
On 8/14/13, Kevin Grittner wrote:
> Robert James wrote:
>
>> I'm confused: What's the difference between
>> col LIKE 'foo%'
>> and
>> col LIKE f1 || '%'
>> ?
>
> The planner knows that 'foo%' doesn't start with a wildcard.
>
>> Either way, it's anchored to the beginning of the string.
>
> No
Hi,
Having a look at the PostgreSQL log may help.
http://stackoverflow.com/questions/71/how-to-log-postgres-sql-queries
You could also try logging in via psql on the database host itself, to
ensure it is not a network issue.
Regards,
Jayadevan
On Wed, Aug 14, 2013 at 2:21 AM, Barth Weishoff
On Thu, Aug 15, 2013 at 6:00 AM, Bruce Momjian wrote:
> Try psql -E, and run the \dT command to see the query it uses.
You have also the following commands:
- ¥dT+, all types with addition information like its size ('var' is
for example variable length)
- ¥dTS+, this includes also the catalog type
On 8/14/2013 5:17 AM, Ivan Radovanovic wrote:
apparently pg_catalog.format_type for some types return quoted name
("char" for example), also I can't find decimal in results (there is
numeric, but I would like to have complete list of supported types, so
decimal should be included too). In docum
Hi all!
We have the following issue. When we use vacuumdb (NOT full) on our
postgres database (~320Gb) it takes up ~10Gb of disk space which is never
returned. Why is the space not returned?
Thanks in advance!
30 matches
Mail list logo
