fix your app. You could maybe make it insert
to_number() calls, but it'd almost certainly be easier to get it to
output numbers in SQL-standard syntax in the first place.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chan
See lc_numeric.
https://www.postgresql.org/docs/current/static/config-setting.html#CONFIG-SETTING-SQL-COMMAND-INTERACTION
https://www.postgresql.org/docs/current/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT
regards, tom lane
--
Sent via pgsql-ge
gal)?
Recommended way is to use SPI:
https://www.postgresql.org/docs/current/static/spi.html
Aside from that documentation, there are lots of examples to study in the
core code and contrib.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postg
.
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
oesn't work syntactically. Don't recall the details
offhand.
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
round to providing such a thing
in core ... probably lack of consensus on what to name the reverse
operator. You'd need to support regex cases as well, so there's
more than one operator name to come up with.
regards, tom lane
--
Sent via pgsql-general mailing lis
um catalog, so you definitely need more space.
Other ways of doing it would have created problems of their own. But
you can certainly build your own enum type if you don't like the tradeoffs
the core code made.
regards, tom lane
--
Sent via pgsql-general mailing l
ere are an infinite number of zeroes
after it seems rather beside the point.
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
TR1, TR2
Later versions of the standard use many more words to say the same thing.
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
al values. While JOIN ON produces all columns from T1 followed
by all columns from T2, JOIN USING produces one output column for each
of the listed column pairs (in the listed order), followed by any
remaining columns from T1, followed by any remaining columns from T2.
w)
As far as that UNION query goes, I think you misunderstand
what UNION does. It doesn't promise to preserve ordering.
You might have gotten the results you expected with UNION
ALL (but they still wouldn't have constituted a valid
JSON array).
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
t that poses a data corruption
risk. (But I've been wrong before.)
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
erusal of the 9.3-branch commit log finds quite a few
LATERAL-related bug fixes that went in since 9.3.6. You might consider
updating to 9.3.something-recent and see if anything changes.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.
te from SQL, whereupon it loses
value for some purposes because you can never be sure that what you're
looking at is the "real" date and not something somebody frobbed later.
OTOH, losing all your creation date info during dump/restore is annoying
too.
regards, tom l
Johann Spies <johann.sp...@gmail.com> writes:
> On 25 August 2017 at 13:48, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Remember that "work_mem" is "work memory per plan node", so a complex
>> query could easily chew up a multiple of that number --
creating a program that opens its own
connection to the DB and sits there listening. psql cannot help you
meaningfully with this request, and I can't see a way to make it do
so that wouldn't be a monstrous kluge.
regards, tom lane
--
Sent via pgsql-general ma
esql.org/docs/current/static/datatype-datetime.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
distinguish named parameters from dollar-quote tags?
For instance, this is legal:
regression=# select $foobar$stuff$foobar$;
?column?
--
stuff
(1 row)
I think you're going to end up with weird corner case behaviors if
you try to squeeze still another meaning into "$letters..."
Dmitry Lazurkin <dila...@gmail.com> writes:
> Thanks. Can I update "pg_proc.probin" without any problems?
Should work. I'd experiment in a scratch database before doing
it in production, but I can't think of a problem offhand.
regards, tom lane
pg_relation_filenode
+--
pg_proc_oid_index |12662
pg_proc|12657
pg_proc_proname_args_nsp_index |12663
(3 rows)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-g
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think the real problem occurs where we realloc the array bigger.
> Looking at the surroundings, I think that it would be nice to have
> pq
ap as well as details about your query to make progress.
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
m,
certainly.
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
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Thu, Aug 24, 2017 at 11:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I haven't tried it, but it sure looks like it would, if you don't hit
>> OOM first. pqAddTuple() isn't doing anything to guard against int
Tiffany Thang <tiffanyth...@gmail.com> writes:
> Thanks Tom. As the superuser, I'm able to create the table in the specific
> tablespace. Does myuser require additional privileges?
Yes, USAGE on the tablespace if memory serves (check the GRANT man page
for details).
> My ai
across
more than one tablespace to get anything in that column.
> "show default_tablespace" is also empty.
If you didn't do anything to change that setting, that would also be
expected. Again, the interpretation is "use the database's default
tablespace".
Igor Korot <ikoro...@gmail.com> writes:
> On Thu, Aug 24, 2017 at 8:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think what we need is to (1) introduce some error checking in libpq so
>> that it reports an error if the resultset exceeds 2G rows --- right now
>>
this
is explained as a library-wide limitation and not just a problem with
PQntuples.
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
NALYZE does not do that. It likewise does not do anything to try
to model the network transmission costs, which are also likely to be
significant if the data is bulky --- but there's no way to do that without
actually sending the result data to the client, AFAICS.
regards,
d temp tables by putting the modifier word right there, rather
than attaching it as an option somewhere later in the command. We should
not let that syntax accident drive what we consider reasonable semantics
to be.
(Also, once you've done all that, do you want to also do it for UNLOGGED
tab
Right, that's why this isn't likely to change. You could replace the
datatype-related limit with a CHECK constraint, and then it'd be possible
for a BEFORE trigger to modify the value to make it compliant before the
constraint is checked.
regards, tom lane
--
Sent via pgsq
ROP TABLE pg_temp.tablename".
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
release. It's possible it was broken for awhile before that, though,
since the reason for killing it was that no one had shown any interest
in testing it in a long time.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
gmb <gmbou...@gmail.com> writes:
> Tom Lane-2 wrote
>> Personally I'd have left the function parameters as text and inserted
>> explicit coercions:
> Just out of curiosity , is there a reason why this will be you preference ?
Well, if the rest of your code thinks that
iate type automatically. But in a
function, those parameters already have types, and they might not be the
most desirable ones for the purpose.
Personally I'd have left the function parameters as text and inserted
explicit coercions:
SELECT count(tablename) = 1 FROM pg_tables
WHERE schemaname =
h word.
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
ate
overhead to have such an index.
In any case, I wouldn't worry about it until you have an actual
performance problem. Trying to tell on toy data what the planner
will do with production-sized data is usually a losing game.
regards, tom lane
--
Sent via pgsql-gen
0 squares with 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
rprising if
you're using the default statistics target of 100 --- that means that the
accuracy of histogram-related predictions can't be expected to be any
better than 1%. If you crank up the stats target (for this column, or
the whole table, or globally) and re-analyze, the estimate should get
better,
one PK
row that "matches" an FK row.
If this is explained anywhere in the user-facing documentation,
I didn't find it in a quick look :-(
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
ALTERs would succeed, and then S2 has no choice but to
respect the results of that DDL.
There are other ways we could define the results of this sort of thing,
but they generally would end up failing one or both of your transactions.
Letting it "just work" is not in the picture.
extension. If the answer
is "nothing" then it wouldn't be hard to add such a statement.
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
Melvin Davidson <melvin6...@gmail.com> writes:
> *UPDATE pg_extensionSET extowner = {oid_of_new_owner} WHERE extowner =
> {oid_from_above_statement};*
Note you'll also have to modify the rows in pg_shdepend that reflect
this ownership property.
regar
uthoritative list of the
symbols meant to be exported from core Postgres to extensions, you could
use that to filter out unnecessary symbols. Unfortunately, no such
list has ever been prepared :-(
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@po
r...@bb-c.de (Rainer J.H. Brandt) writes:
> Tom Lane writes:
>> I bet not. We've seen problems with macOS unexpectedly deciding to
>> filter away inherited environment variables in some situations.
>> It might be useful to put "env >somefile" into the PG makef
ent variables in some situations.
It might be useful to put "env >somefile" into the PG makefile and
compare results between the two ways of invoking it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
ing, it's not unreasonable to write
PQclear(PQexec(conn, "some SQL command"));
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
oyed, which
this coding suggests would happen, then that shouldn't matter ... but
maybe the pointers got copied to somewhere longer-lived? Anyway, there's
nothing visibly wrong with what you showed us, so the problem is somewhere
else.
regards, tom lane
--
Sent via pgsql-g
Igor Korot <ikoro...@gmail.com> writes:
> Is there a way to do such a check from the libpq?
I think the pg_prepared_statements view will help you.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make change
ause we'd definitely have the actual
comparison value at runtime.)
Anyway, sorry, this is a research problem rather than something that's
easy to fix.
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
chive is corrupt enough that it contains
bad SQL, it probably has problems that pg_restore would notice anyway.
Most of the restore failures that we hear about in practice would not be
detectable without actually executing the commands, because they involve
problems like issuing commands in the wrong orde
ATION ... FROM "C"
at all on platforms that lack HAVE_LOCALE_T. There's no good reason
for that IMO; not if we're one line of code away from allowing 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
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 8/1/17 10:53, Tom Lane wrote:
>> I think this is actually a bug, because the collations code clearly
>> means to allow clones of the C/POSIX locales --- see eg lc_collate_is_c,
> You seem to say that we
ng silly errors, just hot-wire the code to assume
ENOENT on Windows.
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
; 1)
-> Seq Scan on c2 (cost=0.00..25.88 rows=423 width=36)
Filter: (f1 > 1)
(5 rows)
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
ated them.
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
oll() if you're trying to invoke
a collation-aware function. It's probably good enough to pass
DEFAULT_COLLATION_OID, although if you're inside a SQL function of
your own, passing down whatever collation was passed to you would
be a better plan.
regards, tom lane
--
o use that if (sid, social) were not the PK of words_social
but just some random unique key.
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
don't have a provision to reload a timezone
definition once read by a given process.
Whether you use --with-system-tzdata doesn't matter; the same would apply
if you were updating a Postgres-private copy of the tzdata files.
regards, tom lane
--
Sent via pgsql-gener
Vincenzo Romano <vincenzo.rom...@notorand.it> writes:
> I would like to understand the typo protection mentioned by Tom earlier:
> I need to understand the reason for creating that special case.
Well, case A:
create function foo(out x int4) returns setof int8 ...
This is indubi
r in another way) ?
I don't know of any version labeling in the tzdata files themselves
(not that I've looked very hard for one). If you know your PG minor
release you could look into our release notes to see what tzdata
release it shipped with.
regards, tom lane
--
Se
| pp_pkey | db|
public | pp | f2 |2 |
Your WHERE clause can't tell the difference between these.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
from simple typos.
If you want a consistent syntax I'd suggest
CREATE OR REPLACE FUNCTION afun1() RETURNS TABLE (ot text) ...
It's still really "setof text" under the hood.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.
"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Mon, Jul 24, 2017 at 3:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The cost to form the inner hash is basically negligible whether it's
>> de-duped or not, but if it's not (known) de-duped then
lly negligible whether it's
de-duped or not, but if it's not (known) de-duped then the cost
estimate for the semijoin is going to rise some, and that discourages
selecting it.
At least in this example, the actual runtimes are basically identical
regardless, so there is no great point in sweating over 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
Greg Atkins <void.is.mean...@gmail.com> writes:
> would you like a bug report to track this?
No, it's already dealt with. In any case, your original email was good
enough --- we track bugs these days more by message-ID than anything else.
regards, tom lane
--
yes, it seems you don't
get a DROP EVENT TRIGGER even with that. Will fix.
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
' ' in version() ) ;
position
--
11
(1 row)
Although possibly what you really want is split_part().
regression=# select split_part(version(), ' ', 2);
split_part
9.5.7
(1 row)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@
greigwise <greigw...@comcast.net> writes:
> If I can provide a pg_dump backup with a db where I can reproduce the error
> and then also my postgresql.conf along with the query, would that be what
> you need for a test case?
Sounds like enough.
regards, tom
more likely to be a failure cascading from something else.
In any case, you haven't provided nearly enough information for anyone
else to investigate this problem. Please see
https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
regards, tom lane
--
Sent vi
on why the superuser would get a "permission denied"
> error.
Matview queries are run as the owner of the matview, so this isn't
as surprising as all that. But if the matview works in your normal
usage, then pg_dump must be doing something wrong, perhaps emitting
grants in the wrong o
John R Pierce <pie...@hogranch.com> writes:
> On 7/20/2017 8:40 PM, Tom Lane wrote:
>> Hm, we need to update that text for the new 2-part version numbering
>> scheme, don't we?
> will 10 return like 100100 if its 10.1, or 11 ?
The latter. The two middle digits w
ero is returned
> if the connection is bad.
Hm, we need to update that text for the new 2-part version numbering
scheme, don't we?
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
Can you extract a test case you wouldn't
mind publishing?
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 nondeterministic query result
deterministic.
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
st| 1
(7 rows)
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
f a SELECT list.
SQL is not the most consistent language in the world to begin with, and
some of these notations are things we inherited from Berkeley PostQUEL
and didn't want to give up, so it's a bit of a mess :-(
regards, tom lane
--
Sent via pgsql-general mailing li
you're missing parentheses around the scalar sub-select.
(Whether fixing that will give the behavior you want is unclear,
but the syntax error is clear.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
PIs would affect *all*
datatypes.
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
oring
more data on-disk than is there now. Whether that would be a good
tradeoff is dubious.
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
t's just not something I'd ever expect to affect a query plan.
TBH, I don't believe it. There are a lot of moving parts here, but
I don't see how that could be relevant.
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
C GG <cgg0...@gmail.com> writes:
> ... Is PostgreSQL smart enough to not have to rewrite the table and simply
> shed the domain for the underlying datatype?
Yes, in recent versions ... don't remember how far back exactly.
regards, tom lane
--
Sent via p
UPDATE; COMMIT.
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
legal member of strings would break all those internal APIs, requiring
touching far more code than anyone would want to do. It'd likely break
a great deal of client-side code as well.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
Stephen Frost <sfr...@snowman.net> writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yeah, that's because eval_const_expressions doesn't know how to fold
>> a constant RowExpr to a simple Const. I have a patch laying about
>> someplace to improve that, but I kee
tag_sim <= '(tag1,1)'::tag_sim))
Planning time: 0.230 ms
Execution time: 0.110 ms
(4 rows)
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
ost of a
nestloop-with-inner-indexscan enough to make the planner choose that way.
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
postgre...@get-experience.com writes:
> Den 15. juli 2017 23:15, skrev Tom Lane:
>> Perhaps you could make your PK be on (id, valid_from, valid_to).
> Doesn't really work because valid_to would change on UPDATE. I'd need to
> update foreign relations with another trigger which wou
E UPDATE trigger, it would take a lot of magic
for things to happen that way ;-).
Perhaps you could make your PK be on (id, valid_from, valid_to).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscrip
, although
EXPLAIN ANALYZE will show a lot of time spent in the FK enforcement
trigger.
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
t should be regular
SQL, and you can see what's failing.
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
ntly more lines of
documentation concerning systemd than we do code.
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
r is
more case-sensitive, for instance.
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
he wrong subtree), and by the same token
insertions may fail to enforce uniqueness. That's pretty corrupt in
my book.
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
encoding setting,
so one way or another you're going to need to switch the terminal
program's character set setting.
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
CTEs are discarded. I thought maybe
there was an exception for FOR UPDATE, but a look at the code says
differently. In any case we would only lock rows the sub-select had
actually read, so if it's not called by the outer statement it would
still be a no-op.
regards, tom lane
rihad <ri...@mail.ru> writes:
> On 07/10/2017 11:07 PM, Tom Lane wrote:
>> ... which that isn't. I'd suggest checking for indexes that might need
>> to be rebuilt with this query borrowed from the regression tests:
> I ran the query on our production database. Zero res
rihad <ri...@mail.ru> writes:
> On 07/10/2017 08:42 PM, Tom Lane wrote:
>> No, your indexes on text/char/varchar columns will be corrupted
>> (because their sort order will now be wrong). If you can reindex
>> them before doing anything more with the database, you'd be
ecause their sort order will now be wrong). If you can reindex
them before doing anything more with the database, you'd be ok
... I think. Testing on a scratch copy of the database would be
a good idea, if this is valuable data.
regards, tom lane
--
Sent via
he exported-functions feature.
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
101 - 200 of 14105 matches
Mail list logo
