using PIC? Are you linking
with any static library that may contain 32-bit objects? That error is
most commonly PIC or arch-mismatch.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
I'll hack the makefile and give it a shot.
No need to hack it, set CFLAGS during configure:
shell]# CFLAGS=-m64 ./configure (options)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
result columns
in different formats, although that is possible in the underlying
protocol.
So I made this possible.)
Can you explain the use case for this? Have you investigated libpqtypes?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing
2. adds the possibility to specify a payload parameter, i.e. executing
in SQL
NOTIFY foo 'payload'; and 'payload' will be delivered to any
listening
backend.
Thank you for implementing this- LISTEN/NOTIFY without a payload has
been a major problem to work around for me.
+1
--
Andrew
bool
+ IsListeningOn(const char *channel)
I think a bsearch would be needed. Very busy servers that make heavy use of
notifies would be quite a penalty.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Joachim Wieland wrote:
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow a...@esilo.com wrote:
I think a bsearch would be needed. Very busy servers that make heavy use of
notifies would be quite a penalty.
In such an environment, how many relations/channels is a backend
typically listening
listening with a large queue would perform
decently behind a linear search. At this point, I have no data either
way; only an assumption based off being burnt by sequential scans in the
past ;)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing
vote no. Maybe the NOTIFY command can include a switch to enable
this behavior. No syntax suggestions at this point.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
at few places in mind that would require more bytes.
Why not 8K, 64K, 256K, 1M or even more? Is there some other factor in play
forcing this limitation?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
come in if released that way.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the limitation comes from slru. The true payload
limit is (8K - struct members) the way this is implemented.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
persistent storage for any payload worth keeping post-session.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
was half-baked. NOTIFY is event-driven, ie. no
polling!
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an understanding of the context in which it was applied.
For example, using our screw driver to remove a splinter would be rather stupid,
IMHO ;)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
its a
side-track to discuss queue vs condition variables. Whether a notify is 20
bytes through the network or 8192 bytes doesn't change its design or purpose,
only its size.
Calling this a creeping feature is quite a leap.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com
. The structure can still be fixed
length but maybe we can bump it to 8k (BLCKSZ)?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
that
would fit in memory or not. This leads me to believe that the only
safety in smaller payloads is *possibly* a smaller chance of bogging it
down, but that all depends on the usage pattern of smaller vs. larger
payloads which is system specific.
--
Andrew Chernow
eSilo, LLC
every bit
concerns are now in
the hands of the DBA.
Incidentally, I'd like to thank Joachim personally for having done this
work,
+1
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
approved.
There is a performance boost to handling arrays and composites in
binary, which we use a lot because there are no stored procedures (note,
not trying to take a jab about stored procedures, just giving an example
of how we use and abuse arrays and composites).
--
Andrew Chernow
eSilo
everyone is worried about :) I'm sure there
are other ways to acocmplish this, but this one seems easiest and keeps
it all centralized. Just like --with-openssl, except that loads
libcrypto.so.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing
Andrew Chernow wrote:
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
I gave this a lot of thought and I do think we could abstract this. The
idea
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
[shrug...] So the packagers will compile it out, and you're still hosed,
or at least any users who'd like to use it are.
Forgot
Alvaro Herrera wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its hooks in _init()
or some
Andrew Dunstan wrote:
Please make sure that any scheme you have along these lines will work on
Windows DLLs too.
Ofcourse: LoadLibrary(), GetProcAddress(), __declspec(dllexport).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Kinda what my last suggestion was. Some tid-bits need to be reside in libpq,
but very little. I was thinking PQtypesEnable(bool) which would dlopen
libpqtypes and map all functions needed. This would leave the function bodies
Andrew Chernow wrote:
When I say I'd accept some hooks into libpq, I mean some hooks that
could be used by either libpgtypes or something that would like to do
something roughly similar but with a different API offered to clients.
The particular hook that you seem to mostly need is the ability
Bruce Momjian wrote:
I don't see requiring users to add -lpqtypes to use these functions as a
problem. The idea is that the default libpq would have enough hooks
that you could use it without modification.
You are correct, brain fart on my part. Not sure where my mind was at
but I
/postgresql/libpq/typesys-0.9b.tar.gz
To sum it up, the main concepts are PQputf, PQgetf and
PQregisterTypeHandler. The other functions maintain a PGparam or
exec/send one.
--
Andrew Chernow
eSilo, LLC
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
as an identifier). Still feels like maybe there
should be a void* in a conn and result used for per-connection/result based info
(libpqtypes or not).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Jeff Davis wrote:
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks for
benefits that
Andrew Chernow wrote:
Any thoughts on the hooking suggested by Tom? It sounds like it should
be generic enough so more than just libpqtypes can make use of it. I
think something of this nature should have input before I do anything.
Possible Hook points: (at least ones needed
(*connHook)(PGconn *conn, int op);
int (*resultHook)(PGconn *conn, PGresult *result, in top);
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
about it.
Almost all of the types that required a PGstruct, are very solid mappings. For
instance, geo types are straight forward, not much to a PGpoint. Geo type
structs were kept very close to the backend.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
and binary
results. So, each type handler already toggles itself based on PQfformat.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Chernow wrote:
Yeah, currently composites and arrays only support binary results in
libpqtypes. This forces any array elementType or any member of a
composite to have a send/recv routine. Using the fallback to text
output approach, this limitation on array elements and composite
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually don't
need very much in libpq. Although, making it somehow generic enough
to be useful to other extensions is a bit tricky. Please, suggestions
would be helpful.
Quick question on the hook concept
Andrew Chernow wrote:
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually
don't need very much in libpq. Although, making it somehow generic
enough to be useful to other extensions is a bit tricky. Please,
suggestions would be helpful.
Quick
, as this could lead to
over-design or guess-design.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
I think Andrew Chernow is fundamentally confused about dynamic linking,
which apache has to use because it doesn't know what type of file it has
to handle, with linking, which is bound to the application code.
pgtypes is bound to the application code so it is not like
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
There is no need to pass hookData to the hook function. libpqtypes already
accesses PGconn and PGresult directly so it can just access the hookData member.
That's a habit you'd really be best advised to stop, if you're going
Andrew Chernow wrote:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
result:
null_field
tupArrSize
client_encoding (need a PGconn for this which might be dead)
pqSetResultError
pqResultAlloc
pqResultStrdup
Also, we
and distributable when separated.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, we are trying to
implement it.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, that need direct access to a result
can include result-int.h. This keeps pg_result and referenced structs
out of libpq-fe.h. From a libpq user's viewpoint, nothing has changed.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
attDesc and tuples, I think it would require more API calls as well.
curBlock, curOffset and spaceLeft were never copied (intialized to zero). We
don't touch these.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Andrew Chernow wrote:
Tom Lane wrote:
Perhaps we could do a partial exposure, where the exported struct
declaration contains public fields and there are some private ones
after that.
I have another idea. It would remove a boat load of members that would
need to be exposed (may remove
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
Shoot! Feels like you always miss something.
The patch uses
Gregory Stark wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide
Andrew Chernow wrote:
/* Only for results returned by PQresultDup. This
* will append a new tuple to res. A PGresAttValue
* is allocated and put at index 'res-ntups'. This
* is similar to pqAddTuple except that the tuples
* table has been pre-allocated. In our case, ntups
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
That doesn't seem to me to fit very well with libpq's
if the return value is NULL. I think the best behavior here is to
check PQerrorMessage when any exec function returns a NULL result,
including pqtypes. If not, I think it could get confusing to the API user.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
PGresult *PQresultDup(
PGconn *conn,
PGresult *res,
int ntups,
int numAttributes,
PGresAttDesc *attDescs);
I don't understand why this is a dup operation. How can you dup
if you are specifying a new tuple descriptor
Andrew Chernow wrote:
For client_encoding and noticeHooks, the conn can be NULL. Previously,
we copied this info from the source result when conn was NULL.
Looks like we don't need client_encoding. My guess is, in our use case
noticeHooks can probably be NULL for the created result
Andrew Chernow wrote:
res = paramexec(conn, param, ...
if(!res)
// check pgconn or pgparam?
// can conn have an old error (false-pos)
We will just always dump the error message into the param. If
PQexecParams fails with a NULL result, we will copy PQerrorMessage over
to param-errMsg
this
and think it demonstrates one of the community's strengths.
Thanks again for your time and suggestions.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
will decrypt
* the bytea field and return text to user.
*/
char text[1024];
PQgetf(res, tup_num, %secure_text, field_num,
sizeof(text), text);
You could make the variable arguments for %secure_text include an
encryption key if you want.
--
Andrew Chernow
eSilo, LLC
every bit counts
http
Martijn van Oosterhout wrote:
On Tue, Apr 15, 2008 at 11:24:43AM -0400, Andrew Chernow wrote:
libpqtypes had a superclassing concept (not much discussed on the
lists) where you could introduce new type handlers that wrapped
existing ones and was desgined exactly for things like this. keep
with, it should just be available.
#include libpqtypes.h
// library-wide init
PQtypesInit(void);
// libpqtypes is ready for use on any conn
That is what we would prefer. We tried to do it with a global array and
a lock, but that has its own problems (namely, all the locking).
--
Andrew Chernow
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Installing it per-conn doesn't get you anything. pqtypes has already
been linked in. If you use PQexec and PQgetvalue, the pqtypes code
pretty much does nothing. So, a per-conn install seems redundant. You
are installing the same
function needs to be called before any real libpq code takes place (in
threaded environments).
merlin
That's interesting. I don't see much need for per-conn hooks in regards
to pqtypes, but I can definately see a reason for other object hook
implementations.
--
Andrew Chernow
eSilo, LLC
was
initially designed as a direct extension to libpq (internal code), but the
community prefered using a generic hook interface that allowed libpqtypes to
work externally.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Merlin Moncure wrote:
With an eye towards sideband utility, we are suggesting:
PQcopyResult(PGresult *dest, const PGresult *src, int numAttributes,
PGresAttDesc *attDescs, int options);
Small correction on that prototype.
PGresult *
PQcopyResult(const PGresult *src, int numAttributes,
;
timestamptz
Wed Jan 29 15:31:42.92214 1997 EST
Is this expected behavior? I am not sure if I am missing something or
my results are wrong. Is there a setting that needs tweaking?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
Try a date that's actually during the EDT
switched to PST.
--
andrew chernow
eSilo, LLC.
--every bit counts
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Sullivan wrote:
On Thu, May 01, 2008 at 09:58:09PM -0400, Andrew Chernow wrote:
The more I think about it, I personally like the display behavior of NTFS
file times over something like EXT3. When I am in EDT, it is useful to
have all display times in that zone (regardless of whether
than a '%'.
* The field names are the composite attribute names.
*/
PQgetf(simple, 0, #int4 #text, a, i4, t, text);
PQclear(simple);
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
rather foreign to me.
Not sure we can fix this issue. We made every attempt to keep things
familiar ... printf/scanf style. It's a new approach for libpq but an
old one for C hacks.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql
commitfest? How would we remove it
from the current one?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on a regular C string e_var. Try this instead:
size_t length = e_var != NULL ? strlen(e_var) : 0;
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
to it in the db? Keep the db more compact and simpler
to manage.
Andrew Chernow
eSilo, LLC
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter wrote:
On Mon, Aug 18, 2008 at 06:09:13PM -0400, Andrew Chernow wrote:
David Fetter wrote:
Folks,
As the things stored in databases grow, we're going to start
needing to think about database objects that 4 bytes of size can't
describe. People are already storing video in lo
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Anyways (back on topic), I am in favor of removing limits from any
section of the database ... not just your suggestion. The end-user
application should impose limits.
That's nice as an abstract principle, but there are only so many
Jeff Davis wrote:
I always find these requests puzzling. Is it really useful to store the
data for a jpeg, video file or a 10GB tar ball in a database column?
One use case is that it can use the existing postgresql protocol,
So can what I am suggesting. How about a user-defined C
I am trying to add support for timestamps in our proposed libpq PGparam patch.
I ran into something I don't really understand. I wasn't sure if it was my
libpq code that was wrong (converts a binary timestamp into a time_t or struct
tm) so I tried it from psql.
Server is using EST (8.3devel)
again,
Andrew
Robert Treat wrote:
On Sunday 09 December 2007 09:44, Andrew Chernow wrote:
I am trying to add support for timestamps in our proposed libpq PGparam
patch. I ran into something I don't really understand. I wasn't sure if it
was my libpq code that was wrong (converts a binary
got it. stored vs. displyed was confusing me.
Andrew
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Okay, thanks. So using WITHOUT TIME ZONE basically means, store the provided
value as UTC. Meaning, 8AM EST NOW() is stored/treated as 8AM UTC.
No, I think you are more confused
like HasCTZSet and forced conversions). I plan to do an
extensive test sometime today. So far, I am getting the correct timestamp
conversions across the board.
Andrew
Michael Meskes wrote:
On Sun, Dec 09, 2007 at 11:54:25AM -0500, Andrew Chernow wrote:
That explains why my libpq code
We will have a 0.6 patch tomorrow. This is not a patch, its a proposal.
The implementation has been adjusted and is now a simple printf-style
interface. This is just a design proposal to see if people like the
idea and interface. Up to this point, we have not provided a formal
proposal;
For starters, if binary results is a feature you wish you could uninvent
then we are probably dead in the water for that reason. This goes to
the core of our concept. If there is no desire to synch client server
in regards to type handling, than this a waste of time. I think all of
this
library users would have no idea whether
the values they provide are being sent as text or binary.
The putf interface currently abstracts how it actually sends it.
Although, you do put a C type rather than a string. There is a putstr
%pqtypstr, which puts the string representation of a type.
your proposal completely glossed over the
issue of exactly what data structure would be exposed to clients for
anything more complex than an integer
Yeah. Forgot to include the below in the proposal and the last email.
Here is the lastest list for complex types. Most have been around since
Here is our updated PGparam extension to the libpq api:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00356.php
We have a patch implementing the following which we are cleaning up. We
are also kicking around some ideas for arrays and possibly composite
types which we may consider if
PQlookupOid(PGconn *conn, char **type_names, Oid *oids, int count);
We are backing away from this (not such a great idea). We are actually
working hard at removing Oid dependencies from our PGparam idea. We
think it is more generic to make the server allow InvalidOid for
composites and
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Both array and record binary recv functions require that the recv'd Oid
match the Oid of what the backend has deduced. We don't think this
behavior gets you very much.
Other than the ability to detect errors before the code goes off
Arunachalam Parthasarathy wrote:
hi,
i would request you to answer the following query:
1. What is the maximum size of data single Bytea entry in column?
i would be thankful to you for the above request
.
P.S : my current reqirement is to add more that 1 gb of data in a
single entry of type
Andrew Chernow wrote:
Arunachalam Parthasarathy wrote:
hi,
i would request you to answer the following query:
1. What is the maximum size of data single Bytea entry in column?
i would be thankful to you for the above request
.
P.S : my current reqirement is to add more that 1 gb of data
When inserting a timetz in binary mode, there are no range checks on the time
value (nor on the zone). In text mode, things are fine:
postgres=# insert into t values ('24:00:00.01-05'::timetz);
ERROR: date/time field value out of range: 24:00:00.01-05
// 24:00:00.01-05
double d =
Tom Lane wrote:
range-checks are present only where needed for the backend to defend itself
Survival is very important, but so is maintaining data integrity. IMHO, data
validation should be as consistent as possible. If the backend refuses data on
one hand but allows it on the other,
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
When dealing with binary, the Oid the client sends may match what the
server thinks but the data is wrong (client sent binary formatted data
of the wrong type). Thus, the only real check we saw was on the data
length (which is rolling
We previously tried to send this proposal/patch, but it never showed up.
We tried twice in a 16 hour period. It might be something with the
attachment, who knows. This time, we are providing a URL instead of
attaching the patch. Please disregard previous emails if they come back
from
Markus Schiltknecht wrote:
Hi,
Andrew Chernow wrote:
It might be something with the attachment, who knows.
Most probably that was the case, yes. The -hackers list is limited,
please use -patches to send patches. ;-)
Regards
Markus
Noted.
In our case, its a little ambiguos whether
Andrew Dunstan wrote:
Andrew Chernow wrote:
Markus Schiltknecht wrote:
Hi,
Andrew Chernow wrote:
It might be something with the attachment, who knows.
Most probably that was the case, yes. The -hackers list is limited,
please use -patches to send patches. ;-)
Regards
Markus
Noted
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
That said, we have been a little dismayed in the lack of comment.
Personally, I'm ignoring this thread, as well as the one on
partitioning, because I'm up to my arse in 8.3-release alligators.
I'm going to try hard not to think about
I think, though, that telling them that they must work on a
certain feature, because that's what the users are asking for, is the
wrong approach. Not to say that is exactly what you are requesting, but
I suggest that is where you are leading.
Cheers,
mark
The more communication between
submission, don't know. One thing
is for sure, the patch submitter is probably the most familiar with it
so should be involved at some level of review preparation. This
distributes the work and attempts to make patches more consistent when
reviewed.
--
Andrew Chernow
eSilo, LLC
every bit counts
http
to authors
who know the most about the patch/feature and have probably followed all
discussions related to it. Updating a wiki or something similar is a
brainless activity.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
, requires extensive testing (more time), etc... I do think it is
overkill to have a wiki entry for a one line patch with a 30 minute life-span
(either thrown out or applied).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
101 - 200 of 332 matches
Mail list logo
