T *
FROM a LEFT JOIN b ON a.id = b.id AND (b.id IS NULL OR a.c <> b.d)
and I can't think of any other formulations after reading the link you
gave---it only seems to talk about binary operators involving columns
from two tables. Second shouldn't be allowed, but I included
Hi,
I had been running postgresql 8.3.7 in freebsd for some time, but
after I changed its postgresql.conf file, it can't start any more
eventhoguh I changed the config back to its original file.
Anything wrong?
Here is the errros:
Jun 26 15:58:52 twp1 postgres[1394]: [1-1] FATAL: could not crea
I copied the sample config file to postgresql workign directory before
trying to start postgresql:
# pwd
/usr/local/share/postgresql
twp1:postgresql # cp postgresql.conf.sample ../../pgsql/data/postgresql.conf
On Fri, Jun 26, 2009 at 4:04 PM, Sam Wun wrote:
> Hi,
>
> I had been running p
probably want to probably want
to do the following when creating the index:
> CREATE INDEX users_nick_index ON users (nickname varchar_pattern_ops);
That will allow PG to use the index in LIKE expressions. For more
details see:
http://www.postgresql.org/docs/current/static/indexes-opclass.ht
You may get better results with increasing
the statistics target[1] for those columns as that will give PG more
information, but if the columns are indeed correlated then that's not
going to help.
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current/static/sql-alter
Hi,
Can anyone explain to me why my system is spawn so many postgress instances?
System: FreeBSD 7.2 Stable I386
RAM: < 1GB
Here is the output of the top command:
Mem: 457M Active, 92M Inact, 150M Wired, 23M Cache, 85M Buf, 18M Free
Swap: 999M Total, 150M Used, 849M Free, 14% Inuse
Here is a lis
e decisions
wouldn't be as forced as you're making it. Design is about picking and
choosing between compromises and without knowing what the choices are
you can't design anything, this is one of the problems with tests.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
..) and the other for
the actual measurement.
Just had a quick flick through your previous posts; and I'd probably
stick with the multiple tables approach. It's the most natural fit to
relational databases and until you know more about the problem (i.e.
you've experienced the data your
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
sam=> SELECT substring('1a','^[0-9]+');
substring
---
1
(1 row)
sam=>
--
Sam http://samason.
unctions like
this get added with each major version. Most useful docs for you are
in:
http://www.postgresql.org/docs/current/static/functions-string.html
You can get to older releases quickly by replacing "current" with things
like "8.2" and "7.4".
--
Sam http:/
#x27;^[0-9]+'),7);
If this is so that you can sort things based on their numeric order, why
not just convert it to an integer rather than doing any padding?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
$ LANGUAGE sql STABLE;
Why not use the to_char function[1]:
SELECT to_char($1,'MMDD');
This is better because TEXT(dateval) doesn't have to give a string back
in the form -MM-DD, it just does by default. Readability also seems
to improve when using to_char.
--
S
On Thu, Jun 04, 2009 at 11:17:39AM -0400, Tom Lane wrote:
> Sam Mason writes:
> > I think that with 8.3 at least I'm going to carry on putting
> > IMMUTABLE on where I think it should be. Consider:
>
> there are corner cases where it's useful to have the function
replace "WHERE fn_i" with "WHERE
fn_v". I read this as it not inlining where I'd expect it to be, or am
I missing something else?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Jun 04, 2009 at 09:48:17AM -0400, Tom Lane wrote:
> Sam Mason writes:
> > If it's an SQL function and marked as IMMUTABLE it should (I believe
> > anyway) get inlined somewhere along the line and take no more overhead
> > than writing it out in full.
>
&g
You need to take care of only one case here: denominator == 0; rest of the
> cases will be handled sanely by the database.
>
> CASE WHEN packet_size = 0 THEN null ELSE cost/packet_size END as unit_cost
Yes; or even shorter:
cost/nullif(packet_size,0) AS unit_cost
--
Sam htt
out its support for arrays.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
r code, or even do
the parsing from XML to something more structured outside PG.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ious versions[2] have been
posted to this list for older versions).
--
Sam http://samason.me.uk/
[1]
http://www.postgresql.org/docs/current/static/functions-xml.html#FUNCTIONS-XML-PROCESSING
[2]
http://archives.postgresql.org/message-id/b88c3460905290021o6870bb46tec88ced0c4064...@mail.gma
same order each time.
Another thing you can get PG to do would be a constraint like:
CHECK (time = date_trunc('minute',time))
this would ensure that you get at-most one entry per minute and that
it's on the minute. This sort of thing should make some sorts of
queries easier.
-
ng one or the other
*exclusively* will add complication. General terms to search for are
Natural keys vs. Surrogate keys.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
matching that buffer id then things are good to go. You could have
a foreign key on this from the data (the "test" table above) and the
database will check that you're only inserting data into it when you say
you are. Transactions will ensure that either everything happens or
nothing doe
On Wed, May 20, 2009 at 03:39:39PM +0100, Howard Cole wrote:
> Sam Mason wrote:
> >Note that when used on the pg_dump process all you're doing is stopping
> >it from writing out the backup. The server process will still be
> >running and waiting for the backup to finish
ecommended to pause the backup for days at a time.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
where all the fields apart from the seconds are zero. Whether
this is useful seems debatable, Richard's suggestion of creating a set
of custom types that do the right thing for you seems like the path of
least resistance.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing
; paramValues[2] = " 123 11";
> r = PQexecPrepared(c, "s1", 3, paramValues, NULL, NULL, 0);
You get an error because " 123 11" isn't a valid literal of an
(undecorated) INTERVAL type. I think PG may do the right thing if you
don't specify the typ
thercol=acoltest) as col2
FROM (SELECT somet, acol+100 AS acoltest FROM mytab2)
GROUP BY somet;
Hope that helps!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
r times out, though the timeout
> value 60 or more seconds.
Even then it's not useful to class it as real-time; nothing "bad"
happens if you don't get a response before timeout the user just gets an
error message. Real-time applies when if you don't get a response the
ings "inside" the database, using NOTIFY or
somesuch? Could you define what you mean by real-time, do you mean
the strict academic meaning or just that you want "interactive" things
happening and it would be annoying if they were delayed by a few tens of
milliseconds (as oppos
On Mon, May 18, 2009 at 06:15:28PM +0100, Sam Mason wrote:
> You need to get the contents of the database from somewhere; the obvious
> choices seem to be an existing copy of the PG database directory, a
> backup of the database, or the original data. Your previous messages
> seem
ages
seem to indicate that you do not have either of the first to items and
so the only choice remaining would be to use the original data.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ying
to solve a problem like the example, it would probably be easiest to
swap the inner and outer queries around, i.e. something like:
SELECT acoltest, MAX(b.t)
FROM (
SELECT acol + 100 as acoltest
FROM mytab2
GROUP BY 1) a LEFT JOIN mytab b ON a.acoltest = b.anothercol
GROUP B
use aggregates
> and grouping on Excel.
Grouping and aggregates are spelled "pivot tables" in Excel and they
work well for a single level, they don't scale to more than one level
though and they require considerably more manual housekeeping than SQL.
As always, it's about picking the right tools for the job!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
can have some more confidence that if you have to get other code
to talk to the database it's actually doing what you want it to be doing
and it's not just Perl being consistent with itself, as it should be.
I know I've saved myself a few times doing similar things like this.
On Thu, May 14, 2009 at 01:57:04PM -0400, Steven Lembark wrote:
> On Thu, 14 May 2009 18:44:57 +0100 Sam Mason wrote:
> > You want to be using whatever language you're generating the parameter
> > from (Perl) to handle the expansion of escape sequences for you. This
> &g
the parameter
from (Perl) to handle the expansion of escape sequences for you. This
will cause the expanded string (i.e. the escapes have been interpreted)
to be sent to Postgres and everything should just work. Unfortunately I
don't use Perl much, so can't give much in the way of a
t'll
get away from the religious argument this seems to have turned into.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ed to drop/delete to completely reinitialize my
> database ?
There are "large objects"[1] remaining in the system. The way I've
removed them in the past was by doing a boring:
DELETE FROM pg_largeobject;
A TRUNCATE could probably be used here as well. I wouldn't go as far as
ueries are only touching a few
columns then it's going to need a lot more disk bandwidth to get a
specific number of rows back from the table.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
7;re connecting to the correct
database then? If you connect with psql and do "\dt" does it show up?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ce the email to
> the list.
The normal array constructor should work:
SELECT ARRAY[MIN(v),MAX(v),AVG(v),STDEV(v)]
FROM (VALUES (1),(3),(4)) x(v);
Not sure why this is better than using separate columns though. Maybe a
new datatype and a custom aggregate would be easier to work with?
--
GUAGE plpgsql;
BEGIN;
INSERT INTO ...
UPDATE ...
UPDATE ...
SELECT failif((SELECT credit FROM users WHERE name = 'mary') < 0,
'error, credit can't be less than zero');
COMMIT;
In general, you're probably better off writing the whole thing in
PREPARE _p(parent) AS INSERT INTO subtable SELECT ($1).*;
EXECUTE _p(new);
DEALLOCATE _p;
however this seems to interact badly with the EXECUTE in plpgsql, not
sure how to work around that.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgre
ing to apply the outer WHERE clause. I'd try changing the
cost of the function first as it should cause PG to do the "right thing"
when you use the function in other queries.
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current/static/sql-createfunction
to decide whether this
should go in; if it's coming from an academic department they will (or
should at least) know how much people dislike these sorts of questions
and will only include them if necessary.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-gener
g for column names. It could be argued that it would be nice if
you got an error in the case of ambiguity like above, but PG doesn't
currently do that.
If you'd written your delete command as:
DELETE FROM testing WHERE testing.id = id;
or better:
DELETE FROM testing t WHERE
usly have different ways
of dealing with the ambiguity, but this has worked well for me so far.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
. You're asking PG for an
invalid date and this is its way of telling you so!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nt_id, s.id AS store_id, point(c.x,c.y) <->
point(s.x,s.y) AS distance
FROM clients c, stores s)
ORDER BY client_id, distance;
I'd also expect there to be some GiST magic that can be weaved to get
the above to work somewhat efficiently.
--
Sam http://samason.me.uk/
--
Sent
we're implementing the tightest security possible
> at every layer. This thread is only one part of the overall
> process as it specifically relates to the database layer.
Yes, that sounds reasonable and to be expected.
Hope that's all somewhat helpful!
--
Sam http://samason.me.
On Fri, Apr 17, 2009 at 09:52:30AM -0400, Bill Moran wrote:
> In response to Sam Mason :
> > For example; you say that you don't trust the application, yet the user
> > must trust the application as they're entering their secret into it.
> > How does the user ascerta
ion
of the program?
Protecting against this in general is, as far as I know, is impossible.
The get out clause is that you're not trying to solve the general case,
you've got a specific set of use cases that you need to solve.
--
Sam http://samason.me.uk/
--
Sent via pgsql-gene
I've had a look in the TODO, but haven't found
anything similar. This is obviously only a win when there are few
distinct values from compared to the number of rows.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
as though what you're trying to do could also be expressed as:
SELECT isin FROM ts_frontend.rec_isins WHERE attachment = 2698120
UNION
SELECT isin FROM ts_frontend.attachment_isins WHERE attachment = 2698120;
not sure if it's part of something larger so this may not be a use
data).col0001, (data).col0101 FROM store;
Would "data" get detoasted once per row, or per column referenced?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
bits of
text, because they're getting TOASTed, should be OK. Also note that
NULL values get compressed into a bitmap at the beginning of the tuple
and so don't take up much space.
Hope that helps!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-gen
OM pg_catalog.pg_database d
JOIN pg_catalog.pg_roles r ON d.datdba = r.oid
ORDER BY 1;
As others have said; the design of PG is such that it's built to assume
you're always connected to exactly one database. I'd guess this is an
artifact from a long time ago when PG didn't have multiple databases.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
as desirable (or feasible)?
Anything can be done, it's just getting people enthusiastic enough to do
it!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
sql-interfaces/2005-02/msg00031.php ),
> but I was curious as to whether that's changed. Basically I need to be
> able to dynamically determine what databases exist etc before performing
> certain actions in my application.
What's wrong with "template1" as in the above
e
the code across to the new version of the table and get rid of the view
when you're done.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Apr 09, 2009 at 08:16:55PM +0200, Marcin Krol wrote:
> Sam Mason wrote:
> >On Thu, Apr 09, 2009 at 07:25:42PM +0200, Marcin Krol wrote:
> >>SELECT h.id, r.id, r.start_date, r.end_date
> >> FROM hosts h
> >>LEFT JOIN (reservation_hosts m INN
On Thu, Apr 09, 2009 at 07:25:42PM +0200, Marcin Krol wrote:
> Sam Mason wrote:
> >This is a big hint that things are going wrong. You need those quotes
> >in there, an "integer" is a plain number and not a date.
>
> This one does work in the sense of selecting out
ypes. You may need to
> add explicit type casts.
This is a big hint that things are going wrong. You need those quotes
in there, an "integer" is a plain number and not a date.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
would let this sort of
thing through I think, but newer versions will give an error.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
r.id = m.reservation_id
AND m.host_id IS NOT NULL
AND (r.start_date,r.end_date) OVERLAPS
(${requested_start},${requested_end})
ORDER BY h.id, r.start_date)
The formatting is somewhat grim, but I think it should do what you want.
--
Sam http://samason.me.uk/
--
Sent via pgsql-gen
ific date".
If that's correct; you've got a couple of choices, either turn the inner
join into an outer join and move it up to join onto the hosts, or get
rid of it completely and use the DISTINCT ON clause.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (
xecuting the "pg_ctl.exe start", that would be great !
I think you can pass options to CreateProcess that will cause it to
"hide" the window; not sure if this is what you want but I've not
programmed under Windows for a long time so can't suggest more.
--
Sam
E or Nothing respectively and non-NULL values as
(SOME v) or (Just v).
--
Sam http://samason.me.uk/
[1] http://www.standardml.org/Basis/option.html
[2] http://www.haskell.org/onlinereport/maybe.html
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
Craig Ringer3381.4%
Ivan Sergio Borgonovo 314 1.3%
Sam Mason 3101.3%
Raymond O'Donnell 2701.1%
Martijn van Oosterhout 2641.1%
Greg Smith 2521.0%
The remaining ~2000 distinct addresses were less than one percent each.
I di
y aren't you looking at the postmaster's log? Not sure where this
lives under Windows, but it should tell you why the server is closing
the connection.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
hen you won't have a problem.
If you want to optimise this case you could also look at CLUSTERing this
table on the keyword.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Apr 03, 2009 at 11:09:56AM +0200, Ivan Sergio Borgonovo wrote:
> On Fri, 3 Apr 2009 02:05:19 +0100 Sam Mason wrote:
> > On Thu, Apr 02, 2009 at 09:48:33PM +0200, Ivan Sergio Borgonovo wrote:
> > > I didn't find any elegant example of cursor use in PHP... OK PH
...
Not sure about PG, but the C api pretty much always buffers everything
in memory first. There was mention of getting control of this, but I've
got no idea where it got.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Apr 02, 2009 at 12:06:01PM -0700, David E. Wheeler wrote:
> On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
> >Yes, I'd be tempted to pick one and go with it. It's seems a
> >completely arbitrary choice one way or the other but the current
> >behaviour is cert
empted to pick one and go with it. It's seems a completely
arbitrary choice one way or the other but the current behaviour is
certainly wrong.
I'd go with returning a zero element array because it would do
the "right thing" more often when paired with array_to_string.
I've also b
was
"simply illegal" for it to do anything else. There are choices for
either and a choice needs to be made or the situation should somehow be
made impossible.
> I would argue against a change to have string_to_array('',',') throw an
> error.
I'd agre
For large datasets this
obviously doesn't work well. CURSORs are you friend here.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
tatic/spi.html
If it's going to be "outside" PG and connect to the database to do its
work you want to use the client libraries:
http://www.postgresql.org/docs/current/static/libpq.html
Hope that helps!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list
ser to make a choice
is a bad design decision---the user doesn't need to put a coalesce
in and hence their code will probably break in strange ways when
they're not expecting it. Nobody suggest adding a third parameter to
string_to_array, please!
The general mantra that seems to apply
case because it allows:
string_to_array(array_to_string(col,','),',')
to do the right thing whether it's got zero or more elements in. With
the current implementation you get a NULL back in the case of zero
elements and the expected array back the rest of the time.
T
a,b'
array_to_string('{a,NULL,b}'::TEXT[],',') => 'a,b'
string_to_array('',',') => '{}'
string_to_array(' ',',')=> '{" "}'
string_to_array(',',',')=&
xpect 3,2,1 and 1.
That's also a disingenuous example; what would you expect back from:
select count_elements(string_to_array('butter,,milk',','))
I think the semantics you want is what you'd get from:
array_filter_blanks(string_to_array($1,$2))
wher
add a pair
of functions like:
CREATE FUNCTION array_filter_blanks(TEXT[]) RETURNS TEXT[]
LANGUAGE SQL IMMUTABLE STRICT AS $$
ARRAY(SELECT s FROM unnest($1) AS s WHERE s <> '') $$;
CREATE FUNCTION array_nullif(ANYARRAY,ANYELEMENT) RETURNS ANYARRAY
LANGUAGE SQL IMMUTA
said data back; it doesn't
seem to matter if it actually gets lost! Sounds as though the main
unanswered constraint on the database at the moment is what people what
to do with the data once they've handed it to you. When you've figured
that out you may have a better id
esn't sound like a good choice to be making in the long run.
If you don't know what's going on; try leaving the data you're unsure
about in a spreadsheet until you understand it better. It's much easier
that way than rewriting user interfaces every day because somebo
terpret the path and attribute special meaning
to backslashes then they will indeed break, but very few programs seem
to do this.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l the appropriate libraries as
well which may be a bit of a fiddle---especially to keep up to date.
Then again, if you're building it yourself you'd need all the libraries
anyway so you may as well figure out how to get 32bit packages installed
in your 64bit system anyway.
--
Sam http://s
seem to be any index related changes since then so maybe
your hardware isn't doing what it's told to!
> And how do I reindex it?
Just type:
REINDEX connect_idx;
in psql.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgres
he doc is quite correct.
>
> So what is the best way to accomplish a failover from a 64 bit machine to a
> 32 bit machine?
What about running a 32bit build of PG on the 64bit machine?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postg
#x27;s going on in your system when they're
happening.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rather too tersely in my opinion)
that it would be nice if these were supported as well. E.g.
CREATE TABLE foo ( i INT );
SELECT least('(1)'::foo,NULL);
results in an error. When this should be valid.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgs
r doing things differently, it's just that
those should be special cases (i.e. performance hacks) and not the norm.
Admittedly, using something like PGexecParams is a more awkward; but
there are efforts to get decent string interpolation libraries going
that "just work". For ex
having some trigger to "cache" the entry's root "parent_id"
in another column?
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current/static/sql-createindex.html
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
inappropriately named
column to a table. The reason I don't use NATURAL joins is because of
these non-local side effects (i.e. changing a table can cause seemingly
unrelated queries to suddenly stop working). It's a similar reason why
GOTOs and global variables are frowned upon--it&#x
> cannot read (the text of) the stored procedures, but execute only
I believe this can be tied down, yes.
> cannot know the 'existence' of the other databases
I think this is a little trickier to arrange, why would it matter?
--
Sam http://samason.me.uk/
-
Sent via pgsql
my best suggestion. Performance should be better than using regular
expressions.
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current/static/functions-string.html
-
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
h
ov.limit_name
AND lb.breach_end IS NULL
AND lb.max_breach <= ov.max_breach;
I've obviously not tested it, but I think it's correct. It's also got
the advantage of much less duplication of code.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing l
ws and the remaining 10
to 20 supporting tables having a few hundred rows.
I wouldn't expect row counts to be more accurate than a decimal log and
table counts to be more accurate than a ratio of two.
That's my two cents anyway!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general
parsing) and I don't think
it ever gets as far as checking that the value coming back from the
select is a record of the same structure as is on the left hand side.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
x27;t.
You're putting things in the wrong places! The "E" says that the
following literal is using C style escaping. I.e. you want to say:
E'Smith \\& Jones'
Hope that helps!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@p
401 - 500 of 812 matches
Mail list logo
