Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > That's because a quoted literal isn't necessarily a timestamp. Without
> > context it could be anything, and in the context of comparing to a date
> > the planner probably tries to make it a date.
>
> I think the real point here is t
Richard Huxton <[EMAIL PROTECTED]> writes:
> That's because a quoted literal isn't necessarily a timestamp. Without
> context it could be anything, and in the context of comparing to a date
> the planner probably tries to make it a date.
I think the real point here is this:
regression=# select '2
Stefano Buliani wrote:
> Richard,
>
> understand I shouldn't be comparing a date to a timestamp. Fact is I
> need the full timestamp to process other info in the rest of the function.
>
> My question is: why is the planner casting the timestamp to date when I
> run the query from psql and the oth
Stefano Buliani wrote:
> If I run this query from the psql client it works just fine. From the
> function it doesn't return anything.
> What I discovered is that for it to work from the function I need to
> explicitly cast the tradedate variable to DATE (ie '2008-12-08
> 02:00:00'::DATE - Note t
Hello all,
I'm experiencing a strange problem with postgresql 8.3.4.
I have the following table
tx_queue
txid serial
securityid integer
portfolioid integer
datequeued timestamp default now()
tradedate date
numshares numeric(25,7)
transactiontype char(1)
tradeprice numeric(25,7)
every time a new
